Re: [yocto] my wiki page for using OE and meta-ti layer to build for panda ES
Love it! Any chance you could add an 'Advanced' or 'Next Steps' section that shows how to go beyond a minimal build? Like, how to get a working Qt stack into a custom image on the PandaBoard? On Wed, Nov 21, 2012 at 2:44 PM, Robert P. J. Day rpj...@crashcourse.ca wrote: not strictly related to yocto but i figured some folks might be interested in a recipe for using OE and the meta-ti layer to build a bootable system for a panda ES: http://www.crashcourse.ca/wiki/index.php/OE-Core%2C_meta-ti_and_the_PandaBoard_ES feedback welcome. 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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Tune qemuarm settings and build everything except the kernel?
Hi, again---I thought we were switching h/w platforms, but it turns out we'll be sticking with this system for a bit longer. I am guessing its some sort of Tegra CPU which had FPU but no neon unit... Right, it's a Tegra 2 T20, which lacks the NEON extension. we dont have default tunes available readily that are good for tegra but its not hard to create one Erm. :-% I guess 'hard' is relative. Could you provide an extra hint about this? Do you mean I should make a copy of 'tune-cortexa9.inc' and change DEFAULTTUNE from 'cortexa9-neon' to 'cortexa9'? Or, is there a way to include the existing file and override the default? Also, I'm not sure what do to with the 'VFP Tunes'. I found this thread - http://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg09497.html which seems to talk about some of these issues. I think I need to add '-mfpu=vfpv3-d16' to the compiler flags, but, as this is the first 'real' thing I've tried to do with bitbake, I'm unsure how to accomplish this... On Fri, Aug 31, 2012 at 7:00 PM, Khem Raj raj.k...@gmail.com wrote: Hi Evade, Glad it worked for you at first go. Thats quite an achievement for yocto On Fri, Aug 31, 2012 at 2:58 PM, Evade Flow evadef...@gmail.com wrote: Now I'm wondering: is there any easy way to optimize for the actual target(s) a bit more than the qemuarm MACHINE type does? The example Makefiles for the old project all contain this line: CFLAGS = -g -mcpu=arm1136jf-s -O2 -pipe What's the best way to arrange for that '-mcpu' option to be used by all recipes? Also, are there other optimizations I should consider? I'm appending some details about the board in question, as well as the complete output from booting it to a prompt. I'd be ever so grateful if someone could recommend sensible base settings for this system, and explain how to create a Poky 'layer', or 'machine'---or whatever the right nomenclature is---to apply these settings. Sorry for the long post, and thanks in advance for any advice! -- ~ # uname -a Linux localhost 2.6.36.2-WR3.0.2ax_standard #1 SMP PREEMPT Wed Oct 19 21:58:54 EEST 2011 armv7l armv7l armv7l GNU/Linux ODBP D1.0.1 (10.11.2011) ~ # cat /proc/cpuinfo Processor : ARMv7 Processor rev 0 (v7l) processor : 0 BogoMIPS: 1795.68 Features: swp half thumb fastmult vfp edsp vfpv3 vfpv3d16 I am guessing its some sort of Tegra CPU which had FPU but no neon unit there is rich set of tuning available for arm. So you would create configuration file for your machine. May be just start by making a copy of qemuarm.conf then you would select the right tuning require conf/machine/include/tune-arm926ejs.inc currently select arm926 you might want something more appropriate. add conf/machine/include/tune-arm1136jf-s.inc this will get to what you had in old project and you can also go a step further and make it more appropriate for tegra cpu that you have we dont have default tunes available readily that are good for tegra but its not hard to create one Look at e.g on tune-cortexa9.inc you would create something similar for your cpu and then select proper default tunings. Have fun -Khem ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Cloning yocto repos over https
Is there a way to clone yocto repositories (say, poky) over https? As Paul mentioned, there is work in progress to make it possible to clone yocto repos over http. This should be finished in the very near future, but in the meantime, I've created some (very) unofficial mirrors here: http://github.com/yoctoproject-mirrors I have a script running that syncs all of these every 15 minutes or so. Perhaps this will help you until the official HTTP access is available. (Just be advised: I plan to delete these mirrors when they are no longer necessary...) On Tue, Oct 16, 2012 at 6:50 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Friday 11 May 2012 09:35:30 Chin Huat Ang wrote: Is there a way to clone yocto repositories (say, poky) over https? I'm behind a firewall where git port is blocked, getting it opened is a bureaucracy nightmare. Sorry, it's taken us a while to look into this but we have opened a bug to track it - you may wish to add yourself to the CC list: http://bugzilla.yoctoproject.org/show_bug.cgi?id=3263 Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Control which host components are included in ADT output?
Seems you're more interested in generate a SDK for host? I wouldn't say 'more' interested, just... interested. I guess this is a general QA issue. We have components implementing state machines that only communicate via sockets, for example, and don't talk directly to hardware; these can be prototyped and tested on a Desktop Linux system. We have Qt apps that can run either on the target or the host. In general, we've been finding ways to get work done even without target hardware, since boards are scarce and tend to 'walk off' when you're not looking. Unfortunately, each developer on our team seems to do this in a slightly different way. We're 'supposed' to be using Ubuntu 12.04, but one guy uses Ubuntu 12.10, another uses 10.04 because he despises Unity so much, and another prefers Linux Mint. And each goes through a different process of typing 'apt-get install' and manually building missing dependencies until he's able to compile applications on his host system. This isn't the best situation, but so far it hasn't caused any major headaches. The 'ground truth' for the health of the project is based on how apps behave on the target, and apps compiled for the target are ALWAYS built using the same toolchain and libs. Apps compiled for the host are just a convenience for prototyping and testing. Still, it worries me that each developer is making lots of little decisions every day based on feedback from applications compiled for his host using a process that is essentially uncontrolled and variable. It seems I could remove most of the variation by including all required host-side headers and libraries in the same tarball that supplies the target SDK. When I saw these two subdirectories in /opt/poky/1.2.1/sysroots: - armv5te-poky-linux-gnueabi/usr/lib - i686-pokysdk-linux/usr/lib I got the impression that the Yocto ADT could be used to create a complete host SDK as well as a target SDK, but it appears I was mistaken? Do other people have this same 'problem'? What's a good solution? Or... is it not worth worrying about? On Wed, Oct 10, 2012 at 2:14 AM, Zhang, Jessica jessica.zh...@intel.com wrote: Hi Evade, The main purpose of Yocto ADT is for setting up a development environment on your host which allows you to cross develop applications for your target. And there're two key components help you to achieve this: cross-toolchain and sysroot. That's why the sysroot provides you a collection of target libs and all the main focus of ADT manual is for how to customize your sysroot to meet your special development needs. Seems you're more interested in generate a SDK for host? Thanks, Jessica -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Evade Flow Sent: Tuesday, October 09, 2012 3:11 PM To: yocto@yoctoproject.org Subject: [yocto] Control which host components are included in ADT output? I have a question about the ADT and how it selects host SDK components. If I type: % bitbake meta-toolchain-sdk I wind up getting hundreds of target libs when I extract the generated tarball: % pwd /opt/poky/1.2.1/sysroots % ls armv5te-poky-linux-gnueabi/usr/lib | wc -l 696 but a relatively small number of host libs: % ls i686-pokysdk-linux/usr/lib | wc -l 53 Is this normal? Taking libxml2 as an example: % ls -1 armv5te-poky-linux-gnueabi/usr/lib/libxml* armv5te-poky-linux-gnueabi/usr/lib/libxml2.la armv5te-poky-linux-gnueabi/usr/lib/libxml2.so armv5te-poky-linux-gnueabi/usr/lib/libxml2.so.2 armv5te-poky-linux-gnueabi/usr/lib/libxml2.so.2.7.8 % ls -1 i686-pokysdk-linux/usr/lib/libxml* zsh: no matches found: i686-pokysdk-linux/usr/lib/libxml* It seems desirable to have libxml2 be part of the SDK I give to my development team. We have a lot of test applications that can be run on the host, and I don't like the thought of somebody wasting time chasing a bug that turns out to be due to the fact that he is linking against a different (system-installed) version of libxml2 rather than the target version. Skimming the ADT manual, this section seems to hint at a solution: - http://www.yoctoproject.org/docs/current/adt-manual/adt-manual.html#adt-package But I can't quite follow all the steps. :-% It says (using libglade as an example): First, you should generate the ipk file for the libglade package and add it into a working opkg repository. Use these commands: $ bitbake libglade $ bitbake package-index Being totally new to opkg, this lost me. What does the 'package-index' target actually do? Does bitbake add it [libglade] into a working opkg repository for me, or am I supposed to take the output of the command and do something with it? I had a look in these two locations for 'package-index' and came up empty: - http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html - http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref
Re: [yocto] The BitBake equivalent of Hello, World!
Again, thanks *so* much for putting this together. I tried to do this
once before and didn't have the tenacity to stick with it--it is a
surprisingly daunting task. Having a smallest-possible example will, I
think, be really helpful to developers who want to learn how to debug
bitbake and contribute fixes.
Interestingly, I tried running this and got the following result:
bitbake_hello% ../bitbake-1.15.2/bin/bitbake a
The BBPATH variable is not set
DEBUG: Removed the following variables from the environment:
http_proxy, CVS_RSH,
SHLVL, LD_LIBRARY_PATH, EDITOR, SUDO_USER, USERNAME, PROMPT,
PYTHONPATH, SUDO_UID,
RPROMPT, SUDO_COMMAND, SUDO_GID, OLDPWD, MAIL
I guess I either fat-fingered something during cut-and-paste, or it's
due to some difference between the tarball I downloaded and the bitbake
tag you were using. I'm behind a firewall, but I'll see if I can suck
down the the actual git repo through my phone and see if that makes a
difference.
On Tue, Oct 9, 2012 at 6:31 PM, Patrick Turley
patricktur...@gamestop.com wrote:
Success. The file tree depicted at the bottom of this mail is nearly the
smallest, valid BitBake project that prints Hello, World! Here's the
output:
$ ../BitBake/bin/bitbake a
Parsing recipes: 100%
|#| Time:
00:00:00
Parsing of 1 .bb files complete (0 cached, 1 parsed). 1 targets, 0
skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing RunQueue Tasks
NOTE: Running task 1 of 1 (ID: 0,
/home/pturley/Workspace/Hello/LayerA/a.bb, do_build)
NOTE: package None: task do_build: Started
Hello, World!
NOTE: package None: task do_build: Succeeded
NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be
rerun and all succeeded.
A few things to note:
1) This is not the *smallest* such BitBake project. For example, the
DESCRIPTION and PV variables need not be assigned in a.bb. I set those
variables because I wanted show-layers and show-recipes to display
reasonable information.
2) Some of the variables set in bitbake.conf have simplified values. For
example, you would *not* want to use these values if there were multiple
recipes and you had to disambiguate the output from each of them.
3) On the other hand, *all* the variable assignments in bitbake.conf are
*essential* to BitBake itself. If you remove any one of those assignments,
BitBake will either declare an error or die (usually because some internal
variable is set to None and the BitBake code can't handle it).
├── build
│ │
│ ├── classes
│ │ │
│ │ └── base.bbclass
│ │
│ │ +---
│ │ | addtask build
│ │ +---
│ │
│ └── conf
│ │
│ ├── bblayers.conf
│ │
│ │ +---
│ │ | BBLAYERS ?= \
│ │ |/home/pturley/Workspace/Hello/LayerA \
│ │ |
│ │ +---
│ │
│ └── bitbake.conf
│
│ +---
│ | TMPDIR = ${TOPDIR}/tmp
│ | CACHE = ${TMPDIR}/cache
│ | STAMP = ${TMPDIR}/stamps
│ | T = ${TMPDIR}/work
│ | B = ${TMPDIR}
│ +---
│
├── LayerA
│ │
│ ├── a.bb
│ │
│ │ +---
│ │ | DESCRIPTION = Layer A Recipe
│ │ | PN = 'a'
│ │ | PV = '1'
│ │ |
│ │ | python do_build() {
│ │ | bb.plain(Hello, World!);
│ │ | }
│ │ +---
│ │
│ └── conf
│ │
│ └── layer.conf
│
│ +---
│ | BBPATH .= :${LAYERDIR}
│ |
│ | BBFILES += ${LAYERDIR}/*.bb
│ |
│ | BBFILE_COLLECTIONS += A
│ | BBFILE_PATTERN_A := ^${LAYERDIR}/
│ +---
│
└── BitBake
The BitBake directory origin is:
http://git.openembedded.org/bitbake/
I have the 1.15.2 tag checked out, which is what
Yocto denzil uses.
___
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] The BitBake equivalent of Hello, World!
It helps a lot if you run it from the build dir. :-%
build% ../../bitbake/bin/bitbake a
Parsing recipes: 100%
|#|
Time: 00:00:00
Parsing of 1 .bb files complete (0 cached, 1 parsed). 1 targets, 0
skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing RunQueue Tasks
NOTE: Running task 1 of 1 (ID: 0,
/home/evadeflow/projects/bitbake_hello/LayerA/a.bb, do_build)
NOTE: package None: task do_build: Started
Hello, World!
NOTE: package None: task do_build: Succeeded
NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be
rerun and all succeeded.
Thanks again!
On Wed, Oct 10, 2012 at 11:45 AM, Evade Flow evadef...@gmail.com wrote:
Again, thanks *so* much for putting this together. I tried to do this
once before and didn't have the tenacity to stick with it--it is a
surprisingly daunting task. Having a smallest-possible example will, I
think, be really helpful to developers who want to learn how to debug
bitbake and contribute fixes.
Interestingly, I tried running this and got the following result:
bitbake_hello% ../bitbake-1.15.2/bin/bitbake a
The BBPATH variable is not set
DEBUG: Removed the following variables from the environment:
http_proxy, CVS_RSH,
SHLVL, LD_LIBRARY_PATH, EDITOR, SUDO_USER, USERNAME, PROMPT,
PYTHONPATH, SUDO_UID,
RPROMPT, SUDO_COMMAND, SUDO_GID, OLDPWD, MAIL
I guess I either fat-fingered something during cut-and-paste, or it's
due to some difference between the tarball I downloaded and the bitbake
tag you were using. I'm behind a firewall, but I'll see if I can suck
down the the actual git repo through my phone and see if that makes a
difference.
On Tue, Oct 9, 2012 at 6:31 PM, Patrick Turley
patricktur...@gamestop.com wrote:
Success. The file tree depicted at the bottom of this mail is nearly the
smallest, valid BitBake project that prints Hello, World! Here's the
output:
$ ../BitBake/bin/bitbake a
Parsing recipes: 100%
|#| Time:
00:00:00
Parsing of 1 .bb files complete (0 cached, 1 parsed). 1 targets, 0
skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing RunQueue Tasks
NOTE: Running task 1 of 1 (ID: 0,
/home/pturley/Workspace/Hello/LayerA/a.bb, do_build)
NOTE: package None: task do_build: Started
Hello, World!
NOTE: package None: task do_build: Succeeded
NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be
rerun and all succeeded.
A few things to note:
1) This is not the *smallest* such BitBake project. For example, the
DESCRIPTION and PV variables need not be assigned in a.bb. I set those
variables because I wanted show-layers and show-recipes to display
reasonable information.
2) Some of the variables set in bitbake.conf have simplified values. For
example, you would *not* want to use these values if there were multiple
recipes and you had to disambiguate the output from each of them.
3) On the other hand, *all* the variable assignments in bitbake.conf are
*essential* to BitBake itself. If you remove any one of those assignments,
BitBake will either declare an error or die (usually because some internal
variable is set to None and the BitBake code can't handle it).
├── build
│ │
│ ├── classes
│ │ │
│ │ └── base.bbclass
│ │
│ │ +---
│ │ | addtask build
│ │ +---
│ │
│ └── conf
│ │
│ ├── bblayers.conf
│ │
│ │ +---
│ │ | BBLAYERS ?= \
│ │ |/home/pturley/Workspace/Hello/LayerA \
│ │ |
│ │ +---
│ │
│ └── bitbake.conf
│
│ +---
│ | TMPDIR = ${TOPDIR}/tmp
│ | CACHE = ${TMPDIR}/cache
│ | STAMP = ${TMPDIR}/stamps
│ | T = ${TMPDIR}/work
│ | B = ${TMPDIR}
│ +---
│
├── LayerA
│ │
│ ├── a.bb
│ │
│ │ +---
│ │ | DESCRIPTION = Layer A Recipe
│ │ | PN = 'a'
│ │ | PV = '1'
│ │ |
│ │ | python do_build() {
│ │ | bb.plain(Hello, World!);
│ │ | }
│ │ +---
│ │
│ └── conf
│ │
│ └── layer.conf
│
│ +---
│ | BBPATH .= :${LAYERDIR}
│ |
│ | BBFILES
[yocto] Control which host components are included in ADT output?
I have a question about the ADT and how it selects host SDK components. If I type: % bitbake meta-toolchain-sdk I wind up getting hundreds of target libs when I extract the generated tarball: % pwd /opt/poky/1.2.1/sysroots % ls armv5te-poky-linux-gnueabi/usr/lib | wc -l 696 but a relatively small number of host libs: % ls i686-pokysdk-linux/usr/lib | wc -l 53 Is this normal? Taking libxml2 as an example: % ls -1 armv5te-poky-linux-gnueabi/usr/lib/libxml* armv5te-poky-linux-gnueabi/usr/lib/libxml2.la armv5te-poky-linux-gnueabi/usr/lib/libxml2.so armv5te-poky-linux-gnueabi/usr/lib/libxml2.so.2 armv5te-poky-linux-gnueabi/usr/lib/libxml2.so.2.7.8 % ls -1 i686-pokysdk-linux/usr/lib/libxml* zsh: no matches found: i686-pokysdk-linux/usr/lib/libxml* It seems desirable to have libxml2 be part of the SDK I give to my development team. We have a lot of test applications that can be run on the host, and I don't like the thought of somebody wasting time chasing a bug that turns out to be due to the fact that he is linking against a different (system-installed) version of libxml2 rather than the target version. Skimming the ADT manual, this section seems to hint at a solution: - http://www.yoctoproject.org/docs/current/adt-manual/adt-manual.html#adt-package But I can't quite follow all the steps. :-% It says (using libglade as an example): First, you should generate the ipk file for the libglade package and add it into a working opkg repository. Use these commands: $ bitbake libglade $ bitbake package-index Being totally new to opkg, this lost me. What does the 'package-index' target actually do? Does bitbake add it [libglade] into a working opkg repository for me, or am I supposed to take the output of the command and do something with it? I had a look in these two locations for 'package-index' and came up empty: - http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html - http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html What's the best place to look for these kinds of references when I get stuck on something? The ADT docs go on to say: Next, source the environment setup script found in the Yocto Project files. Follow that by setting up the installation destination to point to your sysroot as sysroot_dir. Finally, have an OPKG configuration file conf_file that corresponds to the opkg repository you have just created. $ opkg-cl –f conf_file -o sysroot_dir update $ opkg-cl –f cconf_file -o sysroot_dir \ --force-overwrite install libglade $ opkg-cl –f cconf_file -o sysroot_dir \ --force-overwrite install libglade-dbg $ opkg-cl –f conf_file -o sysroot_dir \ --force-overwrite install libglade-dev sysroot_dir I understand, but what is conf_file? Did bitbake generate this for me? Am I supposed to create one by hand? Where? These instructions are a little hard to follow due to the use of placeholders rather than concrete arguments. I think a complete, explicit example would help a lot here. Also, it seems likely that the above commands would only install a libglade compiled for the target? How would I generate a libglade for the host? Another question is: is there a way to tune the ADT tarball to be a better fit for my needs so that I don't need to add so many packages by hand after-the-fact? Any advice much appreciated, thanks! ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/2] Move 'tag=' for a few SRC_URIs to SRCREV
Sending in response to: - http://lists.yoctoproject.org/pipermail/yocto/2012-September/011802.html Building with BB_NO_NETWORK can fail if recipes specify 'tag=' in SRC_URI, since bitbake must contact the source repository to verify which hash the tag currently points to. Since tags can, in principle, change, current best practice is to omit 'tag=' from SRC_URIs and instead specify the required revision hash in SRCREV. SHA hashes *cannot* change, so they should not need to be checked, in theory; however, bitbake currently has no mechanism for distinguishing between human-friendly tags like 'v2.1.2' and SHA-1 sums like 'fdb6c0402337d9607c7a39155088eaf033742752': both will result in a call to `git ls-remote` to verify the tag, which is problematic for BB_NO_NETWORK builds. The second part of this patch was, I think, already submitted, but not yet applied to master[?]: - http://lists.yoctoproject.org/pipermail/yocto/2012-September/011949.html Evade Flow (2): Move 'tag=' to SRCREV in btrfs-tools recipe Move 'tag=' to SRCREV in mtd-utils recipe .../btrfs-tools/btrfs-tools_git.bb |3 ++- meta/recipes-devtools/mtd/mtd-utils_1.5.0.bb |3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/2] Move 'tag=' to SRCREV in btrfs-tools recipe
Signed-off-by: Evade Flow evadef...@gmail.com
---
.../btrfs-tools/btrfs-tools_git.bb |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb
b/meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb
index c2ae298..e963a74 100644
--- a/meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb
+++ b/meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb
@@ -12,7 +12,8 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=fcb02dc552a041dee27e4b85c7396067
SECTION = base
DEPENDS = util-linux attr
-SRC_URI =
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git;protocol=git;tag=fdb6c0402337d9607c7a39155088eaf033742752;branch=master
+SRCREV = fdb6c0402337d9607c7a39155088eaf033742752
+SRC_URI =
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git;protocol=git
S = ${WORKDIR}/git
--
1.7.9.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 2/2] Move 'tag=' to SRCREV in mtd-utils recipe
Signed-off-by: Evade Flow evadef...@gmail.com
---
meta/recipes-devtools/mtd/mtd-utils_1.5.0.bb |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/mtd/mtd-utils_1.5.0.bb
b/meta/recipes-devtools/mtd/mtd-utils_1.5.0.bb
index 1a9d4d3..bdfb022 100644
--- a/meta/recipes-devtools/mtd/mtd-utils_1.5.0.bb
+++ b/meta/recipes-devtools/mtd/mtd-utils_1.5.0.bb
@@ -6,7 +6,8 @@ LICENSE = GPLv2+
LIC_FILES_CHKSUM = file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
file://include/common.h;beginline=1;endline=17;md5=ba05b07912a44ea2bf81ce409380049c
-SRC_URI =
git://git.infradead.org/mtd-utils.git;protocol=git;tag=ca39eb1d98e736109c64ff9c1aa2a6ecca222d8f
\
+SRCREV = ca39eb1d98e736109c64ff9c1aa2a6ecca222d8f
+SRC_URI = git://git.infradead.org/mtd-utils.git;protocol=git \
file://add-exclusion-to-mkfs-jffs2-git-2.patch
S = ${WORKDIR}/git/
--
1.7.9.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] HTTP-accessible poky repo?
On Fri, Oct 5, 2012 at 10:51 AM, Evade Flow evadef...@gmail.com wrote: I'd like to track yocto development more closely, but I'm stuck behind a restrictive HTTP-only firewall all day at work. Is there an official (or unofficial-but-up-to-date), HTTP-accessible mirror of git://git.yoctoproject.org/poky.git I can clone from? I can create a clone on github and run some cron scripts at home to sync it, but I'd rather not bother if there's already something like this out there... It seems no one is particularly interested in this. Oh, well. FWIW, I put a couple mirrors here: - http://github.com/yoctoproject-mirrors I figured this would make it easier for me to track upstream development from behind the firewall at work. (*Now* I'm sure people will chime in and tell me there's already a complete set of HTTP-accessible mirrors somewhere... :-}) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] HTTP-accessible poky repo?
I'd like to track yocto development more closely, but I'm stuck behind a restrictive HTTP-only firewall all day at work. Is there an official (or unofficial-but-up-to-date), HTTP-accessible mirror of git://git.yoctoproject.org/poky.git I can clone from? I can create a clone on github and run some cron scripts at home to sync it, but I'd rather not bother if there's already something like this out there... ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Can't fetch git SRC_URI via HTTP
I think Paul posted a patch where bitbake will spit out a good error message about such usage Oops, better have a look at: - http://bugzilla.yoctoproject.org/show_bug.cgi?id=3214 I just created this... :-% On Wed, Oct 3, 2012 at 10:07 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Wednesday 03 October 2012 07:04:06 Khem Raj wrote: On Wed, Oct 3, 2012 at 12:39 AM, Julian Scheel jul...@jusst.de wrote: Am Dienstag, den 02.10.2012, 23:52 +0200 schrieb Martin Jansa: On Tue, Oct 02, 2012 at 11:38:08PM +0200, Julian Scheel wrote: Am 02.10.2012 um 23:22 schrieb Martin Jansa martin.ja...@gmail.com: On Tue, Oct 02, 2012 at 05:17:23PM -0400, Evade Flow wrote: I'm trying to build core-image-sato for my Pandaboard ES, following the instructions posted here: - http://maniacbug.wordpress.com/2012/08/03/pandayocto/ Thus, my OE build configuration looks like this: OE Build Configuration: BB_VERSION= 1.15.2 TARGET_ARCH = arm TARGET_OS = linux-gnueabi MACHINE = pandaboard DISTRO= poky DISTRO_VERSION= 1.2.1 TUNE_FEATURES = armv7a vfp neon cortexa9 TARGET_FPU= vfp-neon meta meta-yocto= denzil:65ffa7395055f7e012cb973f63f92380828eed0d meta-ti = (nobranch):30fb40ebc13614a74c2e237927c60ac43e01d1bc I have these lines in my .gitconfig: [http] proxy=http://user:pas...@usaprox.lightning.com:8080 so I'd expect URLs like this one (from the meta-ti layer's linux-omap4_3.1.0.bb recipe) to work fine: SRC_URI = http://dev.omapzoom.org/pub/scm/integration/kernel-ubuntu.git;pro tocol=git;branch=ti-ubuntu-3.1-1282 \ This url seems wrong, it should start with git:// if you want to clone git repo. Because it starts with http:// normal fetch (like wget) was used so it downloaded probably some http code (see that kernel-ubuntu.git file) instead of any relevant source. I ran into the same issue a few days ago. It seems yocto only supports git fetch through servers providing the repositories through the git protocol. A way to use git repositories which are provided through http or https would be quite a good thing to have. That's what protocol param does; Change that to git://dev.omapzoom.org/pub/scm/integration/kernel-ubuntu.git;protocol=htt p;branch=ti-ubuntu-3.1-1282 and you'll get git fetch over http protocol. Nice to know. Actually when I had this issue I tried it the other way round. Use a http url and set protocol to git... Is this noted somewhere in the documentation? I could not find it. I think it would be worth mentioning it in the yocto reference manual as this seems to be a quite common thing to struggle with. I think Paul posted a patch where bitbake will spit out a good error message about such usage Indeed, in fact coincidentally I was just trying to find this thread in my cluttered inbox in order to reply to it mentioning that :) Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Can't fetch git SRC_URI via HTTP
I'm trying to build core-image-sato for my Pandaboard ES, following the instructions posted here: - http://maniacbug.wordpress.com/2012/08/03/pandayocto/ Thus, my OE build configuration looks like this: OE Build Configuration: BB_VERSION= 1.15.2 TARGET_ARCH = arm TARGET_OS = linux-gnueabi MACHINE = pandaboard DISTRO= poky DISTRO_VERSION= 1.2.1 TUNE_FEATURES = armv7a vfp neon cortexa9 TARGET_FPU= vfp-neon meta meta-yocto= denzil:65ffa7395055f7e012cb973f63f92380828eed0d meta-ti = (nobranch):30fb40ebc13614a74c2e237927c60ac43e01d1bc I have these lines in my .gitconfig: [http] proxy=http://user:pas...@usaprox.lightning.com:8080 so I'd expect URLs like this one (from the meta-ti layer's linux-omap4_3.1.0.bb recipe) to work fine: SRC_URI = http://dev.omapzoom.org/pub/scm/integration/kernel-ubuntu.git;protocol=git;branch=ti-ubuntu-3.1-1282 \ file://0001-Makefile.fwinst-fix-install-breakage-for-FW-images-r.patch \ file://defconfig \ From what I can tell, though, bitbake isn't handling this SRC_URI correctly, and I get: ERROR: Command Error: exit status: 1 Output: Applying patch 0001-Makefile.fwinst-fix-install-breakage-for-FW-images-r.patch patching file scripts/Makefile.fwinst Hunk #1 FAILED at 27. 1 out of 1 hunk FAILED -- rejects in file scripts/Makefile.fwinst Patch 0001-Makefile.fwinst-fix-install-breakage-for-FW-images-r.patch does not apply (enforce with -f) ERROR: Function failed: patch_do_patch If I examine the folder: build/tmp/work/pandaboard-poky-linux-gnueabi/linux-omap4-3.1.0-r0 I see that it contains no source code. It does, however, contain a file named 'kernel-ubuntu.git', whose content is exactly the same as you'd get if you typed: wget http://dev.omapzoom.org/pub/scm/integration/kernel-ubuntu.git This seems like a bug, possibly related to one of these: - http://bugzilla.yoctoproject.org/show_bug.cgi?id=3119 - http://bugzilla.yoctoproject.org/show_bug.cgi?id=3175 Maybe this has been fixed since denzil, but... everything I read about the current state of support for the Pandaboard suggests sticking with denzil/gcc 4.6. Is there some workaround I can use to get past this error? Also, assuming these instructions worked for the author of the original blog post, I wonder what the difference is with my setup. Here are my mods to conf/local.conf, in case it's helpful: MACHINE = pandaboard BBMASK = meta-ti/recipes-misc PACKAGE_CLASSES = package_ipk CONNECTIVITY_CHECK_URIS= BB_GENERATE_MIRROR_TARBALLS = 1 SOURCE_MIRROR_URL ?= file:///home/evadeflow/projects/poky-mirror/ INHERIT += own-mirrors And this is my bblayers.conf: # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf # changes incompatibly LCONF_VERSION = 4 BBFILES ?= BBLAYERS ?= \ /home/evadeflow/projects/poky-git/meta \ /home/evadeflow/projects/poky-git/meta-yocto \ /home/evadeflow/projects/poky-git/meta-ti \ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Can't fetch git SRC_URI via HTTP
Change that to git://dev.omapzoom.org/pub/scm/integration/kernel-ubuntu.git;protocol=http;branch=ti-ubuntu-3.1-1282 and you'll get git fetch over http protocol. Ah, right! Thanks, I never considered that. In fact, the original recipe at: - http://github.com/Angstrom-distribution/meta-ti/blob/master/recipes-kernel/linux/linux-omap4_3.1.0.bb specifies a SRC_URI that begins with 'git://'. It seemed natural to change it to 'http://' because this is how the git command line works. But bitbake doesn't like that syntax at all. The change you suggested is building now, and seems to be working fine. Thank you! On Tue, Oct 2, 2012 at 5:52 PM, Martin Jansa martin.ja...@gmail.com wrote: On Tue, Oct 02, 2012 at 11:38:08PM +0200, Julian Scheel wrote: Am 02.10.2012 um 23:22 schrieb Martin Jansa martin.ja...@gmail.com: On Tue, Oct 02, 2012 at 05:17:23PM -0400, Evade Flow wrote: I'm trying to build core-image-sato for my Pandaboard ES, following the instructions posted here: - http://maniacbug.wordpress.com/2012/08/03/pandayocto/ Thus, my OE build configuration looks like this: OE Build Configuration: BB_VERSION= 1.15.2 TARGET_ARCH = arm TARGET_OS = linux-gnueabi MACHINE = pandaboard DISTRO= poky DISTRO_VERSION= 1.2.1 TUNE_FEATURES = armv7a vfp neon cortexa9 TARGET_FPU= vfp-neon meta meta-yocto= denzil:65ffa7395055f7e012cb973f63f92380828eed0d meta-ti = (nobranch):30fb40ebc13614a74c2e237927c60ac43e01d1bc I have these lines in my .gitconfig: [http] proxy=http://user:pas...@usaprox.lightning.com:8080 so I'd expect URLs like this one (from the meta-ti layer's linux-omap4_3.1.0.bb recipe) to work fine: SRC_URI = http://dev.omapzoom.org/pub/scm/integration/kernel-ubuntu.git;protocol=git;branch=ti-ubuntu-3.1-1282 \ This url seems wrong, it should start with git:// if you want to clone git repo. Because it starts with http:// normal fetch (like wget) was used so it downloaded probably some http code (see that kernel-ubuntu.git file) instead of any relevant source. I ran into the same issue a few days ago. It seems yocto only supports git fetch through servers providing the repositories through the git protocol. A way to use git repositories which are provided through http or https would be quite a good thing to have. That's what protocol param does; Change that to git://dev.omapzoom.org/pub/scm/integration/kernel-ubuntu.git;protocol=http;branch=ti-ubuntu-3.1-1282 and you'll get git fetch over http protocol. Cheers, -Julian file://0001-Makefile.fwinst-fix-install-breakage-for-FW-images-r.patch \ file://defconfig \ From what I can tell, though, bitbake isn't handling this SRC_URI correctly, and I get: ERROR: Command Error: exit status: 1 Output: Applying patch 0001-Makefile.fwinst-fix-install-breakage-for-FW-images-r.patch patching file scripts/Makefile.fwinst Hunk #1 FAILED at 27. 1 out of 1 hunk FAILED -- rejects in file scripts/Makefile.fwinst Patch 0001-Makefile.fwinst-fix-install-breakage-for-FW-images-r.patch does not apply (enforce with -f) ERROR: Function failed: patch_do_patch If I examine the folder: build/tmp/work/pandaboard-poky-linux-gnueabi/linux-omap4-3.1.0-r0 I see that it contains no source code. It does, however, contain a file named 'kernel-ubuntu.git', whose content is exactly the same as you'd get if you typed: wget http://dev.omapzoom.org/pub/scm/integration/kernel-ubuntu.git This seems like a bug, possibly related to one of these: - http://bugzilla.yoctoproject.org/show_bug.cgi?id=3119 - http://bugzilla.yoctoproject.org/show_bug.cgi?id=3175 Maybe this has been fixed since denzil, but... everything I read about the current state of support for the Pandaboard suggests sticking with denzil/gcc 4.6. Is there some workaround I can use to get past this error? Also, assuming these instructions worked for the author of the original blog post, I wonder what the difference is with my setup. Here are my mods to conf/local.conf, in case it's helpful: MACHINE = pandaboard BBMASK = meta-ti/recipes-misc PACKAGE_CLASSES = package_ipk CONNECTIVITY_CHECK_URIS= BB_GENERATE_MIRROR_TARBALLS = 1 SOURCE_MIRROR_URL ?= file:///home/evadeflow/projects/poky-mirror/ INHERIT += own-mirrors And this is my bblayers.conf: # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf # changes incompatibly LCONF_VERSION = 4 BBFILES ?= BBLAYERS ?= \ /home/evadeflow/projects/poky-git/meta \ /home/evadeflow/projects/poky-git/meta-yocto \ /home/evadeflow/projects/poky-git/meta-ti \ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- Martin 'JaMa' Jansa jabber: martin.ja
Re: [yocto] build failure on current
Seems it definitely didn't build tar: evadeflow% pwd /home/evadeflow/projects/poky-git/build/tmp/sysroots/i686-linux/usr/bin evadeflow% ls t* tabs tailf taskset tic toe tput tset tunctl tzselect evadeflow% tar --version tar (GNU tar) 1.22 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by John Gilmore and Jay Fenlason. This is on denzil, BTW. (Maybe the check against the tar version was added later?) evadeflow% bitbake core-image-sato WARNING: Host distribution Ubuntu 10.04 LTS has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution. Parsing recipes: 100% |###| Time: 00:00:07 Parsing of 829 .bb files complete (0 cached, 829 parsed). 1105 targets, 34 skipped, 0 masked, 0 errors. OE Build Configuration: BB_VERSION= 1.15.2 TARGET_ARCH = arm TARGET_OS = linux-gnueabi MACHINE = qemuarm DISTRO= poky DISTRO_VERSION= 1.2.1 TUNE_FEATURES = armv5 dsp thumb arm926ejs TARGET_FPU= soft meta meta-yocto= denzil:65ffa7395055f7e012cb973f63f92380828eed0d Maybe I got my build tree into an inconsistent state somehow when I was trying to 'fix' this. I can try rebuilding if it helps, using the original perl archive (not the one I re-tarballed with tar 1.22)... On Thu, Sep 27, 2012 at 6:58 PM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Thursday 27 September 2012 17:55:45 Evade Flow wrote: Fair enough. And I should mention that the error I reported occurs on Ubuntu 10.04. It's not like I wasn't warned. :-} WARNING: Host distribution Ubuntu 10.04 LTS has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution. (Other than this oddity with the perl package, things seem to work fine.) Yeah, it's just a warning :) This issue is rather perplexing. We're supposed to not be using the host tar if it is older than 1.24 due to another bug in earlier versions - if an older version is found we build tar-replacement-native before anything else gets built. Was tar-replacement-native built on the machine where it was failing? You can verify it built by just checking under tmp/sysroots/native sysroot/usr/bin/ to see if tar exists there. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] build failure on current
To answer your questions...
Just to confirm, this is the same path you get if you run cat pseudodone
in your build directory?
Yessir.
evadeflow% cat pseudodone
/home/evadeflow/projects/poky-git/build/tmp/sysroots/i686-linux/usr/bin
... could you put this into a file and run it and tell me
what it prints on your system?
--- snip --
#!/bin/sh
needtar=1
TARVERSION=`tar --version | head -n 1 | cut -d ' ' -f 4`
float_test() {
echo | awk 'END { exit ( !( '$1')); }'
}
Erm... that *specific* bit prints nothing when pasted into a file and
executed. (Is it really supposed to?)
evadeflow% cat temp.sh
#!/bin/sh
needtar=1
TARVERSION=`tar --version | head -n 1 | cut -d ' ' -f 4`
float_test() {
echo | awk 'END { exit ( !( '$1')); }'
}
evadeflow% chmod +x temp.sh
evadeflow% ./temp.sh
evadeflow% ls -la /bin/sh
lrwxrwxrwx 1 root root 9 2010-08-13 05:08 /bin/sh - /bin/bash
evadeflow% tar --version | head -n 1 | cut -d ' ' -f 4
1.22
On Fri, Sep 28, 2012 at 10:34 AM, Paul Eggleton
paul.eggle...@linux.intel.com wrote:
On Friday 28 September 2012 10:16:27 Evade Flow wrote:
Seems it definitely didn't build tar:
evadeflow% pwd
/home/evadeflow/projects/poky-git/build/tmp/sysroots/i686-linux/usr/bin
Just to confirm, this is the same path you get if you run cat pseudodone in
your build directory?
evadeflow% ls t*
tabs tailf taskset tic toetput tset tunctl tzselect
evadeflow% tar --version
tar (GNU tar) 1.22
...
This is on denzil, BTW. (Maybe the check against the tar version was added
later?)
No, the code to do this was there in denzil as well. Here's the code cut out
into a shell script - could you put this into a file and run it and tell me
what it prints on your system?
--- snip --
#!/bin/sh
needtar=1
TARVERSION=`tar --version | head -n 1 | cut -d ' ' -f 4`
float_test() {
echo | awk 'END { exit ( !( '$1')); }'
}
# Tar version 1.24 and onwards handle overwriting symlinks correctly
# but earlier versions do not; this needs to work properly for sstate
float_test $TARVERSION 1.23 needtar=0
echo $needtar
--- snip --
Thanks,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] build failure on current
Erm... that *specific* bit prints nothing when pasted into a file and
executed. (Is it really supposed to?)
No, but the rest of the script (the bit following the blank line that you've
omitted) is...
My bad, sorry. (I really need to read more carefully.) Here's what I get when
I add the missing lines:
evadeflow% cat temp.sh
#!/bin/sh
needtar=1
TARVERSION=`tar --version | head -n 1 | cut -d ' ' -f 4`
float_test() {
echo | awk 'END { exit ( !( '$1')); }'
}
# Tar version 1.24 and onwards handle overwriting symlinks correctly
# but earlier versions do not; this needs to work properly for sstate
float_test $TARVERSION 1.23 needtar=0
echo $needtar
evadeflow% chmod +x temp.sh
evadeflow% ./temp.sh
1
So... it correctly determines that it needs to build tar, but... the built tar
can't unpack the tarball from CPAN:
evadeflow% wget http://www.cpan.org/src/5.0/perl-5.14.2.tar.gz
--2012-09-28 11:46:13-- http://www.cpan.org/src/5.0/perl-5.14.2.tar.gz
Resolving usaprox1.lightning.com... 10.102.184.7
Connecting to usaprox1.lightning.com|10.102.184.7|:8080... connected.
Proxy request sent, awaiting response... 200 OK
Length: 15223598 (15M) [application/x-gzip]
Saving to: `perl-5.14.2.tar.gz'
100%[]
15,223,598 62.2M/s in 0.2s
2012-09-28 11:46:13 (62.2 MB/s) - `perl-5.14.2.tar.gz' saved [15223598/15223598]
evadeflow% ./poky-git/build/tmp/sysroots/i686-linux/usr/bin/tar xf
perl-5.14.2.tar.gz
gzip: stdin: invalid compressed data--crc error
./poky-git/build/tmp/sysroots/i686-linux/usr/bin/tar: Child returned status 1
./poky-git/build/tmp/sysroots/i686-linux/usr/bin/tar: Error is not
recoverable: exiting now
Weird. Anyway, I have a workaround, so it's not a big deal--especially given
that Ubuntu 10.04 isn't officially supported. I'm happy to run any other
tests you can think of to hunt down the cause of this (I've got a pretty fast
build mchine now), but I totally understand if you've got bigger fish to fry
at the moment...
On Fri, Sep 28, 2012 at 11:19 AM, Paul Eggleton
paul.eggle...@linux.intel.com wrote:
On Friday 28 September 2012 11:13:22 Evade Flow wrote:
... could you put this into a file and run it and tell
me
what it prints on your system?
--- snip --
#!/bin/sh
needtar=1
TARVERSION=`tar --version | head -n 1 | cut -d ' ' -f 4`
float_test() {
echo | awk 'END { exit ( !( '$1')); }'
}
Erm... that *specific* bit prints nothing when pasted into a file and
executed. (Is it really supposed to?)
No, but the rest of the script (the bit following the blank line that you've
omitted) is... I wanted to ensure that both the stripping out of the version
and float_test were working.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] build failure on current
Is it definitely tar that's the problem or gzip? ...
Oh! Didn't even think of that. :-% Looks like it's gzip:
evadeflow% gzip -d perl-5.14.2.tar.gz
gzip: perl-5.14.2.tar.gz: invalid compressed data--crc error
Nice find! I'll see about updating my gzip...
On Fri, Sep 28, 2012 at 12:00 PM, Paul Eggleton
paul.eggle...@linux.intel.com wrote:
On Friday 28 September 2012 11:53:53 Evade Flow wrote:
Erm... that *specific* bit prints nothing when pasted into a file and
executed. (Is it really supposed to?)
No, but the rest of the script (the bit following the blank line that
you've omitted) is...
My bad, sorry. (I really need to read more carefully.) Here's what I get
when I add the missing lines:
evadeflow% cat temp.sh
#!/bin/sh
needtar=1
TARVERSION=`tar --version | head -n 1 | cut -d ' ' -f 4`
float_test() {
echo | awk 'END { exit ( !( '$1')); }'
}
# Tar version 1.24 and onwards handle overwriting symlinks correctly
# but earlier versions do not; this needs to work properly for sstate
float_test $TARVERSION 1.23 needtar=0
echo $needtar
evadeflow% chmod +x temp.sh
evadeflow% ./temp.sh
1
So... it correctly determines that it needs to build tar, but... the built
tar can't unpack the tarball from CPAN:
evadeflow% wget http://www.cpan.org/src/5.0/perl-5.14.2.tar.gz
--2012-09-28 11:46:13-- http://www.cpan.org/src/5.0/perl-5.14.2.tar.gz
Resolving usaprox1.lightning.com... 10.102.184.7
Connecting to usaprox1.lightning.com|10.102.184.7|:8080... connected.
Proxy request sent, awaiting response... 200 OK
Length: 15223598 (15M) [application/x-gzip]
Saving to: `perl-5.14.2.tar.gz'
100%[]
15,223,598 62.2M/s in 0.2s
2012-09-28 11:46:13 (62.2 MB/s) - `perl-5.14.2.tar.gz' saved
[15223598/15223598]
evadeflow% ./poky-git/build/tmp/sysroots/i686-linux/usr/bin/tar xf
perl-5.14.2.tar.gz
gzip: stdin: invalid compressed data--crc error
./poky-git/build/tmp/sysroots/i686-linux/usr/bin/tar: Child returned status
1 ./poky-git/build/tmp/sysroots/i686-linux/usr/bin/tar: Error is not
recoverable: exiting now
Weird. Anyway, I have a workaround, so it's not a big deal--especially given
that Ubuntu 10.04 isn't officially supported. I'm happy to run any other
tests you can think of to hunt down the cause of this (I've got a pretty
fast build mchine now), but I totally understand if you've got bigger fish
to fry at the moment...
Is it definitely tar that's the problem or gzip? This would suggest gzip:
http://code.google.com/p/go/issues/detail?id=3443
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] build failure on current
Just to bring this full circle: I finally got the CRC error on my Ubuntu
10.04 build server to go away by adding the following line to
/etc/apt/sources.list:
deb http://archive.ubuntu.com/ubuntu lucid-updates main universe restricted
and then executing:
sudo apt-get install gzip
to update gzip. Thanks, Paul, for all of your help in tracking this
down...
On Fri, Sep 28, 2012 at 12:34 PM, Evade Flow evadef...@gmail.com wrote:
Is it definitely tar that's the problem or gzip? ...
Oh! Didn't even think of that. :-% Looks like it's gzip:
evadeflow% gzip -d perl-5.14.2.tar.gz
gzip: perl-5.14.2.tar.gz: invalid compressed data--crc error
Nice find! I'll see about updating my gzip...
On Fri, Sep 28, 2012 at 12:00 PM, Paul Eggleton
paul.eggle...@linux.intel.com wrote:
On Friday 28 September 2012 11:53:53 Evade Flow wrote:
Erm... that *specific* bit prints nothing when pasted into a file and
executed. (Is it really supposed to?)
No, but the rest of the script (the bit following the blank line that
you've omitted) is...
My bad, sorry. (I really need to read more carefully.) Here's what I get
when I add the missing lines:
evadeflow% cat temp.sh
#!/bin/sh
needtar=1
TARVERSION=`tar --version | head -n 1 | cut -d ' ' -f 4`
float_test() {
echo | awk 'END { exit ( !( '$1')); }'
}
# Tar version 1.24 and onwards handle overwriting symlinks correctly
# but earlier versions do not; this needs to work properly for sstate
float_test $TARVERSION 1.23 needtar=0
echo $needtar
evadeflow% chmod +x temp.sh
evadeflow% ./temp.sh
1
So... it correctly determines that it needs to build tar, but... the built
tar can't unpack the tarball from CPAN:
evadeflow% wget http://www.cpan.org/src/5.0/perl-5.14.2.tar.gz
--2012-09-28 11:46:13-- http://www.cpan.org/src/5.0/perl-5.14.2.tar.gz
Resolving usaprox1.lightning.com... 10.102.184.7
Connecting to usaprox1.lightning.com|10.102.184.7|:8080... connected.
Proxy request sent, awaiting response... 200 OK
Length: 15223598 (15M) [application/x-gzip]
Saving to: `perl-5.14.2.tar.gz'
100%[]
15,223,598 62.2M/s in 0.2s
2012-09-28 11:46:13 (62.2 MB/s) - `perl-5.14.2.tar.gz' saved
[15223598/15223598]
evadeflow% ./poky-git/build/tmp/sysroots/i686-linux/usr/bin/tar xf
perl-5.14.2.tar.gz
gzip: stdin: invalid compressed data--crc error
./poky-git/build/tmp/sysroots/i686-linux/usr/bin/tar: Child returned status
1 ./poky-git/build/tmp/sysroots/i686-linux/usr/bin/tar: Error is not
recoverable: exiting now
Weird. Anyway, I have a workaround, so it's not a big deal--especially given
that Ubuntu 10.04 isn't officially supported. I'm happy to run any other
tests you can think of to hunt down the cause of this (I've got a pretty
fast build mchine now), but I totally understand if you've got bigger fish
to fry at the moment...
Is it definitely tar that's the problem or gzip? This would suggest gzip:
http://code.google.com/p/go/issues/detail?id=3443
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] build failure on current
I'm new to Yocto, but I've seen similar errors that seem to be due to differences in the version of tar on the build server. Everything's fine on this machine: good% tar --version tar (GNU tar) 1.26 but I get CRC errors sometimes on this one: bad% otp-mmes-build% tar --version tar (GNU tar) 1.22 The specific recipe I was having problems with was, I think, perl-native. I couldn't untar/uncompress the perl archive in build/downloads with tar 1.22, but it worked fine with tar 1.26. (I don't have a solution, sorry. Around the same time I noticed this, I found out that the image I was building was supposed to be built on the denzil branch, so I just switched over to denzil and the problem went away.) On Thu, Sep 27, 2012 at 3:20 PM, Rifenbark, Scott M scott.m.rifenb...@intel.com wrote: I am running through the build example for the QS and hit a failure when trying to access git://git.yoctoproject.org/libowl;protocol=git. I started with the tarball here: http://autobuilder.yoctoproject.org/nightly/CURRENT Full transcript. srifenbark@scottrif-desktop:~$ cd poky-0b09e50810162a07ef0aecee91ee32b4a36334a3 srifenbark@scottrif-desktop:~/poky-0b09e50810162a07ef0aecee91ee32b4a36334a3$ source oe-init-build-env You had no conf/local.conf file. This configuration file has therefore been created for you with some default values. You may wish to edit it to use a different MACHINE (target hardware) or enable parallel build options to take advantage of multiple cores for example. See the file for more information as common configuration options are commented. The Yocto Project has extensive documentation about OE including a reference manual which can be found at: http://yoctoproject.org/documentation For more information about OpenEmbedded see their website: http://www.openembedded.org/ You had no conf/bblayers.conf file. The configuration file has been created for you with some default values. To add additional metadata layers into your configuration please add entries to this file. The Yocto Project has extensive documentation about OE including a reference manual which can be found at: http://yoctoproject.org/documentation For more information about OpenEmbedded see their website: http://www.openembedded.org/ ### Shell environment set up for builds. ### You can now run 'bitbake target' Common targets are: core-image-minimal core-image-sato meta-toolchain meta-toolchain-sdk adt-installer meta-ide-support You can also run generated qemu images with a command like 'runqemu qemux86' srifenbark@scottrif-desktop:~/poky-0b09e50810162a07ef0aecee91ee32b4a36334a3/build$ bitbake -k core-image-sato Pseudo is not present but is required, building this first before the main build Parsing recipes: 100% |#| Time: 00:00:48 Parsing of 825 .bb files complete (0 cached, 825 parsed). 1129 targets, 22 skipped, 0 masked, 0 errors. Build Configuration: BB_VERSION= 1.15.3 TARGET_ARCH = i586 TARGET_OS = linux MACHINE = qemux86 DISTRO= poky DISTRO_VERSION= 1.2+snapshot-20120927 TUNE_FEATURES = m32 i586 TARGET_FPU= meta meta-yocto meta-yocto-bsp= unknown:unknown NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks NOTE: Tasks Summary: Attempted 63 tasks of which 0 didn't need to be rerun and all succeeded. Loading cache: 100% |###| ETA: 00:00:00 Loaded 1130 entries from dependency cache. Build Configuration: BB_VERSION= 1.15.3 TARGET_ARCH = i586 TARGET_OS = linux MACHINE = qemux86 DISTRO= poky DISTRO_VERSION= 1.2+snapshot-20120927 TUNE_FEATURES = m32 i586 TARGET_FPU= meta meta-yocto meta-yocto-bsp= unknown:unknown NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks NOTE: validating kernel configuration WARNING: The recipe is trying to install files into a shared area when those files already exist. Those files are: /home/scottrif/poky-0b09e50810162a07ef0aecee91ee32b4a36334a3/build/tmp/sysroots/x86_64-linux/usr/share/sgml/openjade-1.3.2/catalog WARNING: The recipe is trying to install files into a shared area when those files already exist. Those files are: /home/scottrif/poky-0b09e50810162a07ef0aecee91ee32b4a36334a3/build/tmp/sysroots/qemux86/usr/include/python2.7/pyconfig.h /home/scottrif/poky-0b09e50810162a07ef0aecee91ee32b4a36334a3/build/tmp/sysroots/qemux86/usr/lib/libpython2.7.so /home/scottrif/poky-0b09e50810162a07ef0aecee91ee32b4a36334a3/build/tmp/sysroots/qemux86/usr/lib/libpython2.7.so.1.0
Re: [yocto] build failure on current
Something was bugging me about this, so I dug up my notes. I was wrong when I said switching to denzil fixed my problem---it did NOT. I simply cannot untar/uncompress the perl archive from CPAN with tar 1.22: evadeflow% tar --version tar (GNU tar) 1.22 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by John Gilmore and Jay Fenlason. evadeflow% wget http://www.cpan.org/src/5.0/perl-5.14.2.tar.gz --2012-09-27 15:45:23-- http://www.cpan.org/src/5.0/perl-5.14.2.tar.gz Resolving usah1nprox1.al-lighting.com... 10.102.184.7 Connecting to usah1nprox1.al-lighting.com|10.102.184.7|:8080... connected. Proxy request sent, awaiting response... 200 OK Length: 15223598 (15M) [application/x-gzip] Saving to: `perl-5.14.2.tar.gz' 100%[] 15,223,598 480K/s in 31s 2012-09-27 15:45:55 (478 KB/s) - `perl-5.14.2.tar.gz' saved [15223598/15223598] evadeflow% tar xf perl-5.14.2.tar.gz gzip: stdin: invalid compressed data--crc error tar: Child returned status 1 tar: Exiting with failure status due to previous errors The way I 'fixed' this was to unpack/repack the archive on my other build machine (the one with tar 1.26), copy the resultant 'perl-5.14.2' folder to the original machine, retar/compress it with tar 1.22, and place this new perl-5.14.2.tar.gz file in my pre-mirror folder. Anyway, this seems just weird enough that I thought I should mention it on the list... On Thu, Sep 27, 2012 at 3:42 PM, Evade Flow evadef...@gmail.com wrote: I'm new to Yocto, but I've seen similar errors that seem to be due to differences in the version of tar on the build server. Everything's fine on this machine: good% tar --version tar (GNU tar) 1.26 but I get CRC errors sometimes on this one: bad% otp-mmes-build% tar --version tar (GNU tar) 1.22 The specific recipe I was having problems with was, I think, perl-native. I couldn't untar/uncompress the perl archive in build/downloads with tar 1.22, but it worked fine with tar 1.26. (I don't have a solution, sorry. Around the same time I noticed this, I found out that the image I was building was supposed to be built on the denzil branch, so I just switched over to denzil and the problem went away.) On Thu, Sep 27, 2012 at 3:20 PM, Rifenbark, Scott M scott.m.rifenb...@intel.com wrote: I am running through the build example for the QS and hit a failure when trying to access git://git.yoctoproject.org/libowl;protocol=git. I started with the tarball here: http://autobuilder.yoctoproject.org/nightly/CURRENT Full transcript. srifenbark@scottrif-desktop:~$ cd poky-0b09e50810162a07ef0aecee91ee32b4a36334a3 srifenbark@scottrif-desktop:~/poky-0b09e50810162a07ef0aecee91ee32b4a36334a3$ source oe-init-build-env You had no conf/local.conf file. This configuration file has therefore been created for you with some default values. You may wish to edit it to use a different MACHINE (target hardware) or enable parallel build options to take advantage of multiple cores for example. See the file for more information as common configuration options are commented. The Yocto Project has extensive documentation about OE including a reference manual which can be found at: http://yoctoproject.org/documentation For more information about OpenEmbedded see their website: http://www.openembedded.org/ You had no conf/bblayers.conf file. The configuration file has been created for you with some default values. To add additional metadata layers into your configuration please add entries to this file. The Yocto Project has extensive documentation about OE including a reference manual which can be found at: http://yoctoproject.org/documentation For more information about OpenEmbedded see their website: http://www.openembedded.org/ ### Shell environment set up for builds. ### You can now run 'bitbake target' Common targets are: core-image-minimal core-image-sato meta-toolchain meta-toolchain-sdk adt-installer meta-ide-support You can also run generated qemu images with a command like 'runqemu qemux86' srifenbark@scottrif-desktop:~/poky-0b09e50810162a07ef0aecee91ee32b4a36334a3/build$ bitbake -k core-image-sato Pseudo is not present but is required, building this first before the main build Parsing recipes: 100% |#| Time: 00:00:48 Parsing of 825 .bb files complete (0 cached, 825 parsed). 1129 targets, 22 skipped, 0 masked, 0 errors. Build Configuration: BB_VERSION= 1.15.3 TARGET_ARCH = i586 TARGET_OS = linux MACHINE = qemux86 DISTRO= poky DISTRO_VERSION= 1.2+snapshot-20120927 TUNE_FEATURES = m32 i586 TARGET_FPU
Re: [yocto] build failure on current
Fair enough. And I should mention that the error I reported occurs on Ubuntu 10.04. It's not like I wasn't warned. :-} WARNING: Host distribution Ubuntu 10.04 LTS has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution. (Other than this oddity with the perl package, things seem to work fine.) On Thu, Sep 27, 2012 at 3:56 PM, Rifenbark, Scott M scott.m.rifenb...@intel.com wrote: I was told that I hit the server at a busy time thus causing the fetch to fail. I just re-ran it and ran error free. I was also told this was a rare occurrence but it does happen. Scott -Original Message- From: Evade Flow [mailto:evadef...@gmail.com] Sent: Thursday, September 27, 2012 12:42 PM To: Rifenbark, Scott M Cc: yocto@yoctoproject.org Subject: Re: [yocto] build failure on current I'm new to Yocto, but I've seen similar errors that seem to be due to differences in the version of tar on the build server. Everything's fine on this machine: good% tar --version tar (GNU tar) 1.26 but I get CRC errors sometimes on this one: bad% otp-mmes-build% tar --version tar (GNU tar) 1.22 The specific recipe I was having problems with was, I think, perl-native. I couldn't untar/uncompress the perl archive in build/downloads with tar 1.22, but it worked fine with tar 1.26. (I don't have a solution, sorry. Around the same time I noticed this, I found out that the image I was building was supposed to be built on the denzil branch, so I just switched over to denzil and the problem went away.) On Thu, Sep 27, 2012 at 3:20 PM, Rifenbark, Scott M scott.m.rifenb...@intel.com wrote: I am running through the build example for the QS and hit a failure when trying to access git://git.yoctoproject.org/libowl;protocol=git. I started with the tarball here: http://autobuilder.yoctoproject.org/nightly/CURRENT Full transcript. srifenbark@scottrif-desktop:~$ cd poky-0b09e50810162a07ef0aecee91ee32b4a36334a3 srifenbark@scottrif-desktop:~/poky-0b09e50810162a07ef0aecee91ee32b4a36334a3$ source oe-init-build-env You had no conf/local.conf file. This configuration file has therefore been created for you with some default values. You may wish to edit it to use a different MACHINE (target hardware) or enable parallel build options to take advantage of multiple cores for example. See the file for more information as common configuration options are commented. The Yocto Project has extensive documentation about OE including a reference manual which can be found at: http://yoctoproject.org/documentation For more information about OpenEmbedded see their website: http://www.openembedded.org/ You had no conf/bblayers.conf file. The configuration file has been created for you with some default values. To add additional metadata layers into your configuration please add entries to this file. The Yocto Project has extensive documentation about OE including a reference manual which can be found at: http://yoctoproject.org/documentation For more information about OpenEmbedded see their website: http://www.openembedded.org/ ### Shell environment set up for builds. ### You can now run 'bitbake target' Common targets are: core-image-minimal core-image-sato meta-toolchain meta-toolchain-sdk adt-installer meta-ide-support You can also run generated qemu images with a command like 'runqemu qemux86' srifenbark@scottrif-desktop:~/poky-0b09e50810162a07ef0aecee91ee32b4a36334a3/build$ bitbake -k core-image-sato Pseudo is not present but is required, building this first before the main build Parsing recipes: 100% |#| Time: 00:00:48 Parsing of 825 .bb files complete (0 cached, 825 parsed). 1129 targets, 22 skipped, 0 masked, 0 errors. Build Configuration: BB_VERSION= 1.15.3 TARGET_ARCH = i586 TARGET_OS = linux MACHINE = qemux86 DISTRO= poky DISTRO_VERSION= 1.2+snapshot-20120927 TUNE_FEATURES = m32 i586 TARGET_FPU= meta meta-yocto meta-yocto-bsp= unknown:unknown NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks NOTE: Tasks Summary: Attempted 63 tasks of which 0 didn't need to be rerun and all succeeded. Loading cache: 100% |###| ETA: 00:00:00 Loaded 1130 entries from dependency cache. Build Configuration: BB_VERSION= 1.15.3 TARGET_ARCH = i586 TARGET_OS = linux MACHINE = qemux86 DISTRO= poky DISTRO_VERSION= 1.2+snapshot-20120927 TUNE_FEATURES = m32 i586 TARGET_FPU= meta meta-yocto meta-yocto-bsp= unknown:unknown NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue
[yocto] IPK Package name contains illegal characters?
After (finally!) getting all the required sources pre-mirrorred, I was able to the build the 'discovery-image' in the meta-ivi layer in 2 hours + 17 minutes: http://git.yoctoproject.org/cgit/cgit.cgi/meta-ivi/ This was using package_rpm, though, so I thought I could do better by changing conf/local.conf to contain: PACKAGE_CLASSES ?= package_ipk It appears that this was going to be quite a bit faster, but after 1 hour it generated the error: *** Error: Package name contains illegal characters, (other than [a-z0-9.+-]) The extra space between 'name' and 'contains' seems *very* suspicious, but I don't know what to make of it. (The package name is an empty string? Why?) Any suggestions as to how I can debug this? The log file doesn't show what command was attempted, so I really don't know where to begin. In case it's helpful, the tail-end of the output from running 'bitbake -DD DLT-daemon' is appended below. (NOTE: The exact same problem exists for the AudioManager component of the meta-ivi layer...) DEBUG: Stampfile /home/evadeflow/projects/poky-git/build/tmp-eglibc-eglibc/stamps/armv7a-vfp-neon-oe-linux-gnueabi/DLT-daemon-2.5.2-r0.do_compile not available NOTE: Running task 716 of 722 (ID: 8, /home/evadeflow/projects/poky-git/meta-ivi/recipes-extended/DLT-daemon/DLT-daemon_2.5.2.bb, do_compile) NOTE: package DLT-daemon-2.5.2-r0: task do_compile: Started NOTE: package DLT-daemon-2.5.2-r0: task do_compile: Succeeded DEBUG: Marking task 2 (/home/evadeflow/projects/poky-git/meta-ivi/recipes-extended/DLT-daemon/DLT-daemon_2.5.2.bb, do_install) as buildable DEBUG: Stampfile /home/evadeflow/projects/poky-git/build/tmp-eglibc-eglibc/stamps/armv7a-vfp-neon-oe-linux-gnueabi/DLT-daemon-2.5.2-r0.do_install not available NOTE: Running task 717 of 722 (ID: 2, /home/evadeflow/projects/poky-git/meta-ivi/recipes-extended/DLT-daemon/DLT-daemon_2.5.2.bb, do_install) DEBUG: Running /home/evadeflow/projects/poky-git/meta-ivi/recipes-extended/DLT-daemon/DLT-daemon_2.5.2.bb:do_install under fakeroot, fakedirs: /home/evadeflow/projects/poky-git/build/tmp-eglibc-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/DLT-daemon-2.5.2-r0/pseudo/ NOTE: package DLT-daemon-2.5.2-r0: task do_install: Started NOTE: package DLT-daemon-2.5.2-r0: task do_install: Succeeded DEBUG: Marking task 10 (/home/evadeflow/projects/poky-git/meta-ivi/recipes-extended/DLT-daemon/DLT-daemon_2.5.2.bb, do_package) as buildable DEBUG: Marking task 3 (/home/evadeflow/projects/poky-git/meta-ivi/recipes-extended/DLT-daemon/DLT-daemon_2.5.2.bb, do_populate_sysroot) as buildable DEBUG: Stampfile /home/evadeflow/projects/poky-git/build/tmp-eglibc-eglibc/stamps/armv7a-vfp-neon-oe-linux-gnueabi/DLT-daemon-2.5.2-r0.do_package.vexpressa9 not available NOTE: Running task 718 of 722 (ID: 10, /home/evadeflow/projects/poky-git/meta-ivi/recipes-extended/DLT-daemon/DLT-daemon_2.5.2.bb, do_package) DEBUG: Running /home/evadeflow/projects/poky-git/meta-ivi/recipes-extended/DLT-daemon/DLT-daemon_2.5.2.bb:do_package under fakeroot, fakedirs: /home/evadeflow/projects/poky-git/build/tmp-eglibc-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/DLT-daemon-2.5.2-r0/pseudo/ DEBUG: Stampfile /home/evadeflow/projects/poky-git/build/tmp-eglibc-eglibc/stamps/armv7a-vfp-neon-oe-linux-gnueabi/DLT-daemon-2.5.2-r0.do_populate_sysroot.vexpressa9 not available NOTE: Running task 719 of 722 (ID: 3, /home/evadeflow/projects/poky-git/meta-ivi/recipes-extended/DLT-daemon/DLT-daemon_2.5.2.bb, do_populate_sysroot) NOTE: package DLT-daemon-2.5.2-r0: task do_populate_sysroot: Started NOTE: package DLT-daemon-2.5.2-r0: task do_package: Started NOTE: package DLT-daemon-2.5.2-r0: task do_populate_sysroot: Succeeded NOTE: package DLT-daemon-2.5.2-r0: task do_package: Succeeded DEBUG: Marking task 12 (/home/evadeflow/projects/poky-git/meta-ivi/recipes-extended/DLT-daemon/DLT-daemon_2.5.2.bb, do_package_write_ipk) as buildable DEBUG: Stampfile /home/evadeflow/projects/poky-git/build/tmp-eglibc-eglibc/stamps/armv7a-vfp-neon-oe-linux-gnueabi/DLT-daemon-2.5.2-r0.do_package_write_ipk not available NOTE: Running task 720 of 722 (ID: 12, /home/evadeflow/projects/poky-git/meta-ivi/recipes-extended/DLT-daemon/DLT-daemon_2.5.2.bb, do_package_write_ipk) DEBUG: Running /home/evadeflow/projects/poky-git/meta-ivi/recipes-extended/DLT-daemon/DLT-daemon_2.5.2.bb:do_package_write_ipk under fakeroot, fakedirs: /home/evadeflow/projects/poky-git/build/tmp-eglibc-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/DLT-daemon-2.5.2-r0/pseudo/ NOTE: package DLT-daemon-2.5.2-r0: task do_package_write_ipk: Started ERROR: Function failed: opkg-build execution failed ERROR: Logfile of failure stored in: /home/evadeflow/projects/poky-git/build/tmp-eglibc-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/DLT-daemon-2.5.2-r0/temp/log.do_package_write_ipk.27610 Log data follows: | DLT-daemon-systemd | *** Error: Package name contains illegal characters, (other than [a-z0-9.+-]) | | opkg-build: Please fix the above errors and try again. |
Re: [yocto] BB_NO_NETWORK and own-mirrors not working with meta-systemd
Try doing 'bitbake kmod -c cleansstate;bitbake kmod' - does that still fail?
Thanks for the suggestion. I get this when I try to run 'bitbake kmod -c
cleanslate':
ERROR: Task do_cleanslate does not exist for target kmod
Because I don't know any better, I tried this instead:
% bitbake kmod clean
% bitbake kmod
but it yielded the same result:
NOTE: package kmod-7-r0: task do_fetch: Started
ERROR: Function failed: Network access disabled through BB_NO_NETWORK
but access rquested with command git ls-remote
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
8885ced062131214448 (for url None)
I guess I'll try the BFI approach of restarting the build from scratch next.
`:-o. Incidentally, searching the OpenEmbedded manual for 'cleanslate' turns
up no hits. Is this some kind of 'secret' command? Where can I learn about
other such commands?
On Wed, Sep 19, 2012 at 8:13 PM, Gary Thomas g...@mlbassoc.com wrote:
On 2012-09-19 16:30, Evade Flow wrote:
I'm just trying to build the thing. :-) I'll try converting the tag
name into a commit hash and see if that helps, thanks a lot...
::SIGH:: I changed the SRC_URI var in kmod.inc from this:
SRC_URI =
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=v${PV}
to this:
SRC_URI =
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git
SRCREV=8885ced062131214448fae056ef453f094303805
This is *still* trying to access the network:
Try doing 'bitbake kmod -c cleansstate;bitbake kmod' - does that still fail?
NOTE: package kmod-7-r0: task do_fetch: Started
ERROR: Function failed: Network access disabled through BB_NO_NETWORK
but access rquested with command git ls-remote
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
8885ced062131214448 (for url None)
ERROR: Logfile of failure stored in:
/home/dwolfe/projects/poky-git/build/tmp-eglibc-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/kmod-7-r0/temp/log.do_fetch.11168
Log data follows:
| ERROR: Function failed: Network access disabled through
BB_NO_NETWORK but access rquested with command git ls-remote
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
8885ced062131214448 (for url None)
NOTE: package kmod-7-r0: task do_fetch: Failed
NOTE: package acl-2.2.51-r3: task do_fetch: Started
NOTE: package acl-2.2.51-r3: task do_fetch: Succeeded
ERROR: Task 1374
(/home/dwolfe/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
do_fetch) failed with exit code '1'
NOTE: Tasks Summary: Attempted 699 tasks of which 697 didn't need to
be rerun and 1 failed.
Summary: 1 task failed:
/home/dwolfe/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
do_fetch
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
bitbake discovery-image 16.51s user 2.65s system 112% cpu 17.031 total
Why is poky/bitbake/whatever running 'git ls-remote'? This seems like a
bug
On Wed, Sep 19, 2012 at 1:33 PM, Evade Flow evadef...@gmail.com wrote:
I'm not sure how to answer your questions, unfortunately, this is all
quite new to me. I'm not the maintainer of said layer, and don't know
anything at all yet about 'layer etiquette'. There does seem to be a
README.md file in meta-systemd, though:
-
http://git.yoctoproject.org/cgit/cgit.cgi/meta-systemd/tree/README.md
I'm just trying to build the thing. :-) I'll try converting the tag
name into a commit hash and see if that helps, thanks a lot...
On Wed, Sep 19, 2012 at 1:23 PM, Gary Thomas g...@mlbassoc.com wrote:
On 2012-09-19 11:15, Evade Flow wrote:
Where did you get that meta-systemd layer?
From here:
- http://git.yoctoproject.org/cgit/cgit.cgi/meta-systemd/
Why are there conflicting meta-systemd layers (and pointers thereto)??
This layer in git.yoctoproject.org doesn't seem even legal - where is
the README that is expected with every layer? Without it, I don't have
enough info to be able to report problems like yours...
The reason your build fails with BB_NO_NETWORK is that the kmod_7.bb
recipe refers to a git tag, not a specific revision, which cannot be
resolved without using the network.
On Wed, Sep 19, 2012 at 12:50 PM, Gary Thomas g...@mlbassoc.com
wrote:
On 2012-09-19 10:34, Evade Flow wrote:
Trying to build the meta-ivi discovery-image behind a firewall is
proving to be quite a challenge. I tried modifying my conf/local.conf
file as follows:
CONNECTIVITY_CHECK_URIS=
BB_GENERATE_MIRROR_TARBALLS = 1
SOURCE_MIRROR_URL ?= file:///home/evadeflow/projects/poky-mirror/
INHERIT += own-mirrors
and then ran:
% bitbake discovery-image
in a VM on my home laptop over the weekend. (I'm trying to build
using
the meta-ivi layer, per the instructions in its README.) After
grinding
and churning for some 60+ hours, it finally succeeded, leaving 11 GB
of
'stuff' in my poky-mirror folder.
Then, I copied the poky-mirror folder to a firewalled machine at work
and added
Re: [yocto] BB_NO_NETWORK and own-mirrors not working with meta-systemd
Fortunately, you caught me before I pulled out a bigger hammer. :-} I was going to report that this still didn't work after typing: % bitbake -c cleanstate But re-reading your post, I saw that there were supposed to be two 'esses'[!] The following: % bitbake kmod -c cleansstate % bitbake kmod does, in fact, seem to have worked for me. Thanks, guys, for your help! On Thu, Sep 20, 2012 at 9:42 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Thursday 20 September 2012 09:30:19 Evade Flow wrote: I guess I'll try the BFI approach of restarting the build from scratch next. `:-o. We'd really rather people didn't do this as it does not help us to diagnose and fix problems. Incidentally, searching the OpenEmbedded manual for 'cleanslate' turns up no hits. Is this some kind of 'secret' command? Where can I learn about other such commands? As Gary pointed out the command is cleansstate. The OpenEmbedded manual has not been kept up-to-date I'm afraid - but the good news is there is an up-to- date and comprehensive set of documentation set provided by the Yocto Project here: http://www.yoctoproject.org/documentation FYI you can do bitbake -c listtasks targetname which will list all of the valid tasks, you can remove do_ from the start of these to get commands you can use with -c. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BB_NO_NETWORK and own-mirrors not working with meta-systemd
To bring this full circle... if you want to build behind a restrictive
firewall using pre-mirrored sources and BB_NO_NETWORK, be aware that
recipes which:
1. Specify a git repo as the source, and,
2. Specify the revision to be built using a tag name
will cause your build to abort when bitbake tries to run 'git ls-remote'
to resolve the tag name. So don't specify SRC_URI like this:
SRC_URI =
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=v${PV}
Instead, use:
SRC_URI =
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=8885ced062131214448fae056ef453f094303805;branch=master
I added a note about this to the Wiki:
-
http://wiki.yoctoproject.org/wiki/How_do_I#Non-networked_Builds_and_Cached_Git_Respositories
I'm still new to Yocto, so someone please chime in if any of this
information is incorrect...
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] BB_NO_NETWORK and own-mirrors not working with meta-systemd
Trying to build the meta-ivi discovery-image behind a firewall is proving to be quite a challenge. I tried modifying my conf/local.conf file as follows: CONNECTIVITY_CHECK_URIS= BB_GENERATE_MIRROR_TARBALLS = 1 SOURCE_MIRROR_URL ?= file:///home/evadeflow/projects/poky-mirror/ INHERIT += own-mirrors and then ran: % bitbake discovery-image in a VM on my home laptop over the weekend. (I'm trying to build using the meta-ivi layer, per the instructions in its README.) After grinding and churning for some 60+ hours, it finally succeeded, leaving 11 GB of 'stuff' in my poky-mirror folder. Then, I copied the poky-mirror folder to a firewalled machine at work and added: BB_NO_NETWORK=1 to local.conf. When I tried to bitbake discovery-image on this machine, I got the following error: NOTE: Running task 697 of 3568 (ID: 1374, /home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb, do_fetch) NOTE: package kmod-7-r0: task do_fetch: Started ERROR: Function failed: Network access disabled through BB_NO_NETWORK but access rquested with command git ls-remote git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git v7 (for url None) ERROR: Logfile of failure stored in: /home/evadeflow/projects/poky-git/build/tmp-eglibc-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/kmod-7-r0/temp/log.do_fetch.29423 Log data follows: | ERROR: Function failed: Network access disabled through BB_NO_NETWORK but access rquested with command git ls-remote git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git v7 (for url None) NOTE: package kmod-7-r0: task do_fetch: Failed ERROR: Task 1374 (/home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb, do_fetch) failed with exit code '1' Waiting for 1 running tasks to finish: 0: libusb1-1.0.8-r4 do_compile (pid 29232) NOTE: package libusb1-1.0.8-r4: task do_compile: Succeeded NOTE: Tasks Summary: Attempted 697 tasks of which 105 didn't need to be rerun and 1 failed. Summary: 1 task failed: /home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb, do_fetch Summary: There was 1 ERROR message shown, returning a non-zero exit code. bitbake discovery-image 5338.15s user 995.52s system 187% cpu 56:12.92 total [NOTE: I'm on poky denzil@65ffa73, meta-ivi denzil@e068388, and meta-systemd denzil@6a358e9. Also, that typo in the output isn't mine, i.e., 'rquested' should be 'requested'.] Can anyone explain what's going on here? If I look in the poky-mirror folder for kmod-related stuff, I see: % ls /home/evadeflow/projects/poky-mirror/*kmod* /home/evadeflow/projects/poky-mirror/git2_git.kernel.org.pub.scm.utils.kernel.kmod.kmod.git.tar.gz /home/evadeflow/projects/poky-mirror/git2_git.profusion.mobi.kmod.git.tar.gz I *think* this is what needs to be downloaded for this recipe(?) Why is `git ls-remote` being run at all? I'm not sure whether this is the fault of poky/oe-core, or of the meta-systemd layer. I'd just really wish it worked. `:-} Any advice? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BB_NO_NETWORK and own-mirrors not working with meta-systemd
Where did you get that meta-systemd layer? From here: - http://git.yoctoproject.org/cgit/cgit.cgi/meta-systemd/ On Wed, Sep 19, 2012 at 12:50 PM, Gary Thomas g...@mlbassoc.com wrote: On 2012-09-19 10:34, Evade Flow wrote: Trying to build the meta-ivi discovery-image behind a firewall is proving to be quite a challenge. I tried modifying my conf/local.conf file as follows: CONNECTIVITY_CHECK_URIS= BB_GENERATE_MIRROR_TARBALLS = 1 SOURCE_MIRROR_URL ?= file:///home/evadeflow/projects/poky-mirror/ INHERIT += own-mirrors and then ran: % bitbake discovery-image in a VM on my home laptop over the weekend. (I'm trying to build using the meta-ivi layer, per the instructions in its README.) After grinding and churning for some 60+ hours, it finally succeeded, leaving 11 GB of 'stuff' in my poky-mirror folder. Then, I copied the poky-mirror folder to a firewalled machine at work and added: BB_NO_NETWORK=1 to local.conf. When I tried to bitbake discovery-image on this machine, I got the following error: NOTE: Running task 697 of 3568 (ID: 1374, /home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb, do_fetch) NOTE: package kmod-7-r0: task do_fetch: Started ERROR: Function failed: Network access disabled through BB_NO_NETWORK but access rquested with command git ls-remote git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git v7 (for url None) ERROR: Logfile of failure stored in: /home/evadeflow/projects/poky-git/build/tmp-eglibc-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/kmod-7-r0/temp/log.do_fetch.29423 Log data follows: | ERROR: Function failed: Network access disabled through BB_NO_NETWORK but access rquested with command git ls-remote git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git v7 (for url None) NOTE: package kmod-7-r0: task do_fetch: Failed ERROR: Task 1374 (/home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb, do_fetch) failed with exit code '1' Waiting for 1 running tasks to finish: 0: libusb1-1.0.8-r4 do_compile (pid 29232) NOTE: package libusb1-1.0.8-r4: task do_compile: Succeeded NOTE: Tasks Summary: Attempted 697 tasks of which 105 didn't need to be rerun and 1 failed. Summary: 1 task failed: /home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb, do_fetch Summary: There was 1 ERROR message shown, returning a non-zero exit code. bitbake discovery-image 5338.15s user 995.52s system 187% cpu 56:12.92 total [NOTE: I'm on poky denzil@65ffa73, meta-ivi denzil@e068388, and meta-systemd denzil@6a358e9. Also, that typo in the output isn't mine, i.e., 'rquested' should be 'requested'.] Can anyone explain what's going on here? If I look in the poky-mirror folder for kmod-related stuff, I see: % ls /home/evadeflow/projects/poky-mirror/*kmod* /home/evadeflow/projects/poky-mirror/git2_git.kernel.org.pub.scm.utils.kernel.kmod.kmod.git.tar.gz /home/evadeflow/projects/poky-mirror/git2_git.profusion.mobi.kmod.git.tar.gz I *think* this is what needs to be downloaded for this recipe(?) Why is `git ls-remote` being run at all? I'm not sure whether this is the fault of poky/oe-core, or of the meta-systemd layer. I'd just really wish it worked. `:-} Any advice? Where did you get that meta-systemd layer? I can't find your recipe nor that revision (denzil@6a358e9) in the published version which is at git://git.openembedded.org/meta-openembedded according to http://www.openembedded.org/wiki/LayerIndex -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ 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] BB_NO_NETWORK and own-mirrors not working with meta-systemd
I'm not sure how to answer your questions, unfortunately, this is all quite new to me. I'm not the maintainer of said layer, and don't know anything at all yet about 'layer etiquette'. There does seem to be a README.md file in meta-systemd, though: - http://git.yoctoproject.org/cgit/cgit.cgi/meta-systemd/tree/README.md I'm just trying to build the thing. :-) I'll try converting the tag name into a commit hash and see if that helps, thanks a lot... On Wed, Sep 19, 2012 at 1:23 PM, Gary Thomas g...@mlbassoc.com wrote: On 2012-09-19 11:15, Evade Flow wrote: Where did you get that meta-systemd layer? From here: - http://git.yoctoproject.org/cgit/cgit.cgi/meta-systemd/ Why are there conflicting meta-systemd layers (and pointers thereto)?? This layer in git.yoctoproject.org doesn't seem even legal - where is the README that is expected with every layer? Without it, I don't have enough info to be able to report problems like yours... The reason your build fails with BB_NO_NETWORK is that the kmod_7.bb recipe refers to a git tag, not a specific revision, which cannot be resolved without using the network. On Wed, Sep 19, 2012 at 12:50 PM, Gary Thomas g...@mlbassoc.com wrote: On 2012-09-19 10:34, Evade Flow wrote: Trying to build the meta-ivi discovery-image behind a firewall is proving to be quite a challenge. I tried modifying my conf/local.conf file as follows: CONNECTIVITY_CHECK_URIS= BB_GENERATE_MIRROR_TARBALLS = 1 SOURCE_MIRROR_URL ?= file:///home/evadeflow/projects/poky-mirror/ INHERIT += own-mirrors and then ran: % bitbake discovery-image in a VM on my home laptop over the weekend. (I'm trying to build using the meta-ivi layer, per the instructions in its README.) After grinding and churning for some 60+ hours, it finally succeeded, leaving 11 GB of 'stuff' in my poky-mirror folder. Then, I copied the poky-mirror folder to a firewalled machine at work and added: BB_NO_NETWORK=1 to local.conf. When I tried to bitbake discovery-image on this machine, I got the following error: NOTE: Running task 697 of 3568 (ID: 1374, /home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb, do_fetch) NOTE: package kmod-7-r0: task do_fetch: Started ERROR: Function failed: Network access disabled through BB_NO_NETWORK but access rquested with command git ls-remote git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git v7 (for url None) ERROR: Logfile of failure stored in: /home/evadeflow/projects/poky-git/build/tmp-eglibc-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/kmod-7-r0/temp/log.do_fetch.29423 Log data follows: | ERROR: Function failed: Network access disabled through BB_NO_NETWORK but access rquested with command git ls-remote git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git v7 (for url None) NOTE: package kmod-7-r0: task do_fetch: Failed ERROR: Task 1374 (/home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb, do_fetch) failed with exit code '1' Waiting for 1 running tasks to finish: 0: libusb1-1.0.8-r4 do_compile (pid 29232) NOTE: package libusb1-1.0.8-r4: task do_compile: Succeeded NOTE: Tasks Summary: Attempted 697 tasks of which 105 didn't need to be rerun and 1 failed. Summary: 1 task failed: /home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb, do_fetch Summary: There was 1 ERROR message shown, returning a non-zero exit code. bitbake discovery-image 5338.15s user 995.52s system 187% cpu 56:12.92 total [NOTE: I'm on poky denzil@65ffa73, meta-ivi denzil@e068388, and meta-systemd denzil@6a358e9. Also, that typo in the output isn't mine, i.e., 'rquested' should be 'requested'.] Can anyone explain what's going on here? If I look in the poky-mirror folder for kmod-related stuff, I see: % ls /home/evadeflow/projects/poky-mirror/*kmod* /home/evadeflow/projects/poky-mirror/git2_git.kernel.org.pub.scm.utils.kernel.kmod.kmod.git.tar.gz /home/evadeflow/projects/poky-mirror/git2_git.profusion.mobi.kmod.git.tar.gz I *think* this is what needs to be downloaded for this recipe(?) Why is `git ls-remote` being run at all? I'm not sure whether this is the fault of poky/oe-core, or of the meta-systemd layer. I'd just really wish it worked. `:-} Any advice? Where did you get that meta-systemd layer? I can't find your recipe nor that revision (denzil@6a358e9) in the published version which is at git://git.openembedded.org/meta-openembedded according to http://www.openembedded.org/wiki/LayerIndex -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BB_NO_NETWORK and own-mirrors not working with meta-systemd
I'm just trying to build the thing. :-) I'll try converting the tag
name into a commit hash and see if that helps, thanks a lot...
::SIGH:: I changed the SRC_URI var in kmod.inc from this:
SRC_URI =
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=v${PV}
to this:
SRC_URI =
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git
SRCREV=8885ced062131214448fae056ef453f094303805
This is *still* trying to access the network:
NOTE: package kmod-7-r0: task do_fetch: Started
ERROR: Function failed: Network access disabled through BB_NO_NETWORK
but access rquested with command git ls-remote
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
8885ced062131214448 (for url None)
ERROR: Logfile of failure stored in:
/home/dwolfe/projects/poky-git/build/tmp-eglibc-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/kmod-7-r0/temp/log.do_fetch.11168
Log data follows:
| ERROR: Function failed: Network access disabled through
BB_NO_NETWORK but access rquested with command git ls-remote
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
8885ced062131214448 (for url None)
NOTE: package kmod-7-r0: task do_fetch: Failed
NOTE: package acl-2.2.51-r3: task do_fetch: Started
NOTE: package acl-2.2.51-r3: task do_fetch: Succeeded
ERROR: Task 1374
(/home/dwolfe/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
do_fetch) failed with exit code '1'
NOTE: Tasks Summary: Attempted 699 tasks of which 697 didn't need to
be rerun and 1 failed.
Summary: 1 task failed:
/home/dwolfe/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
do_fetch
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
bitbake discovery-image 16.51s user 2.65s system 112% cpu 17.031 total
Why is poky/bitbake/whatever running 'git ls-remote'? This seems like a
bug
On Wed, Sep 19, 2012 at 1:33 PM, Evade Flow evadef...@gmail.com wrote:
I'm not sure how to answer your questions, unfortunately, this is all
quite new to me. I'm not the maintainer of said layer, and don't know
anything at all yet about 'layer etiquette'. There does seem to be a
README.md file in meta-systemd, though:
- http://git.yoctoproject.org/cgit/cgit.cgi/meta-systemd/tree/README.md
I'm just trying to build the thing. :-) I'll try converting the tag
name into a commit hash and see if that helps, thanks a lot...
On Wed, Sep 19, 2012 at 1:23 PM, Gary Thomas g...@mlbassoc.com wrote:
On 2012-09-19 11:15, Evade Flow wrote:
Where did you get that meta-systemd layer?
From here:
- http://git.yoctoproject.org/cgit/cgit.cgi/meta-systemd/
Why are there conflicting meta-systemd layers (and pointers thereto)??
This layer in git.yoctoproject.org doesn't seem even legal - where is
the README that is expected with every layer? Without it, I don't have
enough info to be able to report problems like yours...
The reason your build fails with BB_NO_NETWORK is that the kmod_7.bb
recipe refers to a git tag, not a specific revision, which cannot be
resolved without using the network.
On Wed, Sep 19, 2012 at 12:50 PM, Gary Thomas g...@mlbassoc.com wrote:
On 2012-09-19 10:34, Evade Flow wrote:
Trying to build the meta-ivi discovery-image behind a firewall is
proving to be quite a challenge. I tried modifying my conf/local.conf
file as follows:
CONNECTIVITY_CHECK_URIS=
BB_GENERATE_MIRROR_TARBALLS = 1
SOURCE_MIRROR_URL ?= file:///home/evadeflow/projects/poky-mirror/
INHERIT += own-mirrors
and then ran:
% bitbake discovery-image
in a VM on my home laptop over the weekend. (I'm trying to build using
the meta-ivi layer, per the instructions in its README.) After grinding
and churning for some 60+ hours, it finally succeeded, leaving 11 GB of
'stuff' in my poky-mirror folder.
Then, I copied the poky-mirror folder to a firewalled machine at work
and added:
BB_NO_NETWORK=1
to local.conf. When I tried to bitbake discovery-image on this machine,
I got the following error:
NOTE: Running task 697 of 3568 (ID: 1374,
/home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
do_fetch)
NOTE: package kmod-7-r0: task do_fetch: Started
ERROR: Function failed: Network access disabled through BB_NO_NETWORK
but access rquested with command git ls-remote
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git v7 (for url
None)
ERROR: Logfile of failure stored in:
/home/evadeflow/projects/poky-git/build/tmp-eglibc-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/kmod-7-r0/temp/log.do_fetch.29423
Log data follows:
| ERROR: Function failed: Network access disabled through
BB_NO_NETWORK but access rquested with command git ls-remote
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git v7 (for url
None)
NOTE: package kmod-7-r0: task do_fetch: Failed
ERROR: Task 1374
(/home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
do_fetch) failed with exit code '1'
Waiting for 1 running tasks to finish:
0
Re: [yocto] ERROR: Nothing RPROVIDES 'libsegfault'
Ah, right--sorry, you did say the denzil *branch*. It seems to be building fine now, thanks. So far, it's gotten through the first 150 tasks, which is a lot further than before. I'll follow up if I encounter any other problems... On Fri, Sep 7, 2012 at 1:08 AM, Florin Sarbu florin.sa...@windriver.com wrote: Please use the denzil branch for poky, not a denzil tag. Thanks, Florin On 09/06/2012 11:02 PM, Evade Flow wrote: Thanks for confirming that the target for meta-ivi is denzil. After re-targetting to branch denzil-7.0.1, I got the following error: -- Pseudo is not present but is required, building this first before the main build Parsing recipes...NOTE: Error expanding variable populate_packages NOTE: Error during finalise of /media/acme/remus/poky-git/meta-ivi/recipes-graphics/mesa/mesa-dri_8.0.1.bb ERROR: Unable to parse /media/acme/remus/poky-git/meta-ivi/recipes-graphics/mesa/mesa-dri_8.0.1.bb NOTE: Error expanding variable populate_packages NOTE: Error during finalise of /media/acme/remus/poky-git/meta-ivi/recipes-graphics/pango/pango_1.28.4.bb ERROR: Command execution failed: Traceback (most recent call last): File /media/acme/remus/poky-git/bitbake/lib/bb/command.py, line 84, in runAsyncCommand self.cooker.updateCache() File /media/acme/remus/poky-git/bitbake/lib/bb/cooker.py, line 1202, in updateCache if not self.parser.parse_next(): File /media/acme/remus/poky-git/bitbake/lib/bb/cooker.py, line 1669, in parse_next self.virtuals += len(result) UnboundLocalError: local variable 'result' referenced before assignment Summary: There were 2 ERROR messages shown, returning a non-zero exit code. -- I attempted a trivial fix for this (see below), and then got: -- Pseudo is not present but is required, building this first before the main build Loading cache...done. Loaded 3 entries from dependency cache. Parsing recipes...NOTE: Error expanding variable populate_packages NOTE: Error during finalise of /media/acme/remus/poky-git/meta-ivi/recipes-graphics/mesa/mesa-dri_8.0.1.bb ERROR: Unable to parse /media/acme/remus/poky-git/meta-ivi/recipes-graphics/mesa/mesa-dri_8.0.1.bb NOTE: Error expanding variable populate_packages NOTE: Error during finalise of /media/acme/remus/poky-git/meta-ivi/recipes-graphics/pango/pango_1.28.4.bb ERROR: Command execution failed: Traceback (most recent call last): File /media/acme/remus/poky-git/bitbake/lib/bb/command.py, line 84, in runAsyncCommand self.cooker.updateCache() File /media/acme/remus/poky-git/bitbake/lib/bb/cooker.py, line 1202, in updateCache if not self.parser.parse_next(): File /media/acme/remus/poky-git/bitbake/lib/bb/cooker.py, line 1671, in parse_next if parsed: UnboundLocalError: local variable 'parsed' referenced before assignment Summary: There were 2 ERROR messages shown, returning a non-zero exit code. -- The patch I tried was: diff --git a/bitbake/lib/bb/cooker.py b/bitbake/lib/bb/cooker.py index 4a4dc38..a2cac9a 100644 --- a/bitbake/lib/bb/cooker.py +++ b/bitbake/lib/bb/cooker.py @@ -1644,6 +1644,8 @@ class CookerParser(object): yield result def parse_next(self): +result = [] +parsed = 0 try: parsed, result = self.results.next() except StopIteration: After this attempted fix, I got the following errors: -- Pseudo is not present but is required, building this first before the main build Loading cache...done. Loaded 3 entries from dependency cache. Parsing recipes...NOTE: Error expanding variable populate_packages NOTE: Error during finalise of /media/acme/remus/poky-git/meta-ivi/recipes-graphics/mesa/mesa-dri_8.0.1.bb ERROR: Unable to parse /media/acme/remus/poky-git/meta-ivi/recipes-graphics/mesa/mesa-dri_8.0.1.bb NOTE: Error expanding variable populate_packages NOTE: Error during finalise of /media/acme/remus/poky-git/meta-ivi/recipes-graphics/pango/pango_1.28.4.bb ERROR: No recipes available for: /media/acme/remus/poky-git/meta-yocto/recipes-core/uclibc/uclibc_git.bbappend /media/acme/remus/poky-git/meta-yocto/recipes-kernel/linux/linux-yocto_3.2.bbappend /media/acme/remus/poky-git/meta-yocto/recipes-bsp/formfactor/formfactor_0.0.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-connectivity/openssl/openssl_1.0.0j.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-kernel/kmod/kmod_git.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-core-ivi/eglibc/eglibc-locale_2.16.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-core-ivi/tinylogin/tinylogin_1.4.bbappend /media/acme/remus/poky-git/meta-yocto/recipes-graphics/mesa/mesa-dri_7.11.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-core-ivi/eglibc/eglibc_2.16.bbappend /media/acme/remus/poky-git/meta-yocto/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend /media/acme/remus/poky-git/meta-ivi
[yocto] ERROR: Nothing RPROVIDES 'libsegfault'
I'm seeing this error while trying to 'bitbake discovery-image' from the meta-ivi layer, according to the instructions here: - http://git.yoctoproject.org/cgit/cgit.cgi/meta-ivi/tree/README.md The complete output looks like this: Loading cache...done. Loaded 1162 entries from dependency cache. Parsing recipes...done. Parsing of 858 .bb files complete (857 cached, 1 parsed). 1159 targets, 39 skipped, 0 masked, 0 errors. Build Configuration: BB_VERSION= 1.15.3 TARGET_ARCH = arm TARGET_OS = linux-gnueabi MACHINE = vexpressa9 DISTRO= poky-ivi-systemd DISTRO_VERSION= E-0.2+snapshot-20120906 TUNE_FEATURES = armv7a vfp neon cortexa9 TARGET_FPU= vfp-neon meta meta-yocto= master:0f55a5868457300a3defc7fa7451ef191d19e018 meta-ivi = master:d2be84764e15003603f08e950308dae7d0ffa9a2 meta-systemd = master:ff33e6271934c747396c307e51dc3e5a5a1f75b8 NOTE: Resolving any missing task queue dependencies ERROR: Nothing RPROVIDES 'libsegfault' (but /media/acme/remus/poky-git/meta/recipes-core/packagegroups/packagegroup-core-standalone-sdk-target.bb RDEPENDS on or otherwise requires it) NOTE: Runtime target 'libsegfault' is unbuildable, removing... Missing or unbuildable dependency chain was: ['libsegfault'] NOTE: Runtime target 'packagegroup-core-standalone-sdk-target' is unbuildable, removing... Missing or unbuildable dependency chain was: ['packagegroup-core-standalone-sdk-target', 'libsegfault'] ERROR: Required build target 'discovery-image' has no buildable providers. Missing or unbuildable dependency chain was: ['discovery-image', 'packagegroup-core-standalone-sdk-target', 'libsegfault'] Summary: There were 2 ERROR messages shown, returning a non-zero exit code. Being fairly new to Yocto/bitbake, I'm not sure how to begin troubleshooting this. Any suggestions? (Note: this is from poky master as of this morning. It may be that meta-ivi doesn't--and isn't intended to--work with the bleeding edge poky sources. I'm just trying to get my head around how to sort out conflicts like this...) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ERROR: Nothing RPROVIDES 'libsegfault'
/recipes-core-ivi/coreutils/coreutils_6.9.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-connectivity/ofono/ofono_1.10.bbappend /media/acme/remus/poky-git/meta-yocto/recipes-core/psplash/psplash_git.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-multimedia/gstreamer/gst-plugins-good_0.10.31.bbappend /media/acme/remus/poky-git/meta-yocto/recipes-gnome/tasks/task-core-sdk-gmae.bbappend /media/acme/remus/poky-git/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-kernel/linux/linux-yocto_3.0.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-multimedia/alsa/alsa-utils_1.0.25.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-connectivity/bluez/bluez4_4.101.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-bsp/usbutils/usbutils_006.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-core-ivi/base-files/base-files_3.0.14.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-support-ivi/attr/acl_2.2.51.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-support-ivi/libcap/libcap_2.22.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-extended/shadow/shadow_4.1.4.3.bbappend /media/acme/remus/poky-git/meta-yocto/recipes-kernel/linux/linux-yocto_2.6.37.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-devtools/gcc/libgcc_4.7.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-bsp/u-boot/u-boot_2011.06.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-extended/shadow-securetty/shadow-securetty_4.1.4.3.bbappend /media/acme/remus/poky-git/meta-yocto/recipes-core/tasks/task-core-tools-profile.bbappend /media/acme/remus/poky-git/meta-yocto/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-devtools/e2fsprogs/e2fsprogs_1.42.1.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-core-ivi/ncurses/ncurses_5.9.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-multimedia/pulseaudio/pulseaudio_2.1.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-connectivity/connman/connman_1.4.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-core-ivi/busybox/busybox_1.20.2.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-kernel/linux/linux-yocto_3.4.bbappend /media/acme/remus/poky-git/meta-yocto/recipes-qt/qt4/qt4-x11-free_4.7.4.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-connectivity/portmap/portmap_6.0.bbappend /media/acme/remus/poky-git/meta-yocto/recipes-gnome/tasks/task-core-standalone-gmae-sdk-target.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-qt/qt4/qt4-native_4.8.1.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-extended/bash/bash_3.2.48.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-support-ivi/libusb/libusb1_1.0.8.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-core-ivi/util-linux/util-linux_2.21.2.bbappend /media/acme/remus/poky-git/meta-yocto/recipes-graphics/mesa/mesa-dri_git.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-support-ivi/libusb/libusb-compat_0.1.3.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-connectivity/wpa-supplicant/wpa-supplicant_1.0.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-connectivity/openssh/openssh_6.0p1.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-core-ivi/base-passwd/base-passwd_3.5.24.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-core-ivi/dbus/dbus_1.6.4.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-multimedia/gstreamer/gst-plugins-base_0.10.36.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-connectivity/nfs-utils/nfs-utils_1.2.3.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-extended/pam/libpam_1.1.6.bbappend ERROR: Command execution failed: Exited with 1 Summary: There were 3 ERROR messages shown, returning a non-zero exit code. -- I'm out of ideas now. `:-} (Actually, I remember now that it was these errors that made me decide to try poky master instead of denzil in the first place.) Any idea what might be wrong? On Thu, Sep 6, 2012 at 3:31 PM, Florin Sarbu florin.sa...@windriver.com wrote: Hi, discovery-image is supposed to work with the denzil branch of poky. Please checkout that branch and let us know if you encounter any other issues. Thanks, Florin On 09/06/2012 10:22 PM, Evade Flow wrote: I'm seeing this error while trying to 'bitbake discovery-image' from the meta-ivi layer, according to the instructions here: - http://git.yoctoproject.org/cgit/cgit.cgi/meta-ivi/tree/README.md The complete output looks like this: Loading cache...done. Loaded 1162 entries from dependency cache. Parsing recipes...done. Parsing of 858 .bb files complete (857 cached, 1 parsed). 1159 targets, 39 skipped, 0 masked, 0 errors. Build Configuration: BB_VERSION= 1.15.3 TARGET_ARCH = arm TARGET_OS = linux-gnueabi MACHINE = vexpressa9 DISTRO= poky-ivi-systemd DISTRO_VERSION= E-0.2
[yocto] Tune qemuarm settings and build everything except the kernel?
Hello, all! I've recently been tapped to bootstrap an embedded Linux project at work and create some demos on hardware left over from an earlier effort. I normally work higher up the application stack, compiling programs using a cross toolchain and sysroot created by some unlucky coworker. In the past, I've just been given a VM and some code to hack on, and instructions for cross-compiling it and getting it on the target. Now I'm being asked to create that ecosystem for a small team. It hasn't yet been determined what the final hardware will be, so I somehow need to create a framework to allow developers to start working with these older systems, and 'port' it when the new hardware becomes available. It seems the Yocto Project exists to solve exactly this sort of problem, but... I don't quite know where to start. On the plus side, the root filesystem for the old development kits resides by default on an attached USB stick. I'm hoping I don't need to mess with the old board's kernel at this early stage, as it already has hardware-accelerated drivers and such that I'd rather not tangle with unless/until necessary. With that preamble, my question is: can I use Yocto/Poky to build a cross-compiler, sysroot and root filesystem for an existing system without also building the kernel? What do I need to type to make it build everything *except* for the kernel? I *did* manage to download poky-denzil-7.0.1 and run 'bitbake core-image-minimal' after sourcing oe-init-build-env and setting MACHINE to 'qemuarm' in conf/local.conf. After that, I copied everything in tmp/work/qemuarm-poky-linux-gnueabi/core-image-minimal-1.0-r0/rootfs to a USB stick and... it actually worked! It made me want to hug Yocto/Poky. I'm all in!! Now I'm wondering: is there any easy way to optimize for the actual target(s) a bit more than the qemuarm MACHINE type does? The example Makefiles for the old project all contain this line: CFLAGS = -g -mcpu=arm1136jf-s -O2 -pipe What's the best way to arrange for that '-mcpu' option to be used by all recipes? Also, are there other optimizations I should consider? I'm appending some details about the board in question, as well as the complete output from booting it to a prompt. I'd be ever so grateful if someone could recommend sensible base settings for this system, and explain how to create a Poky 'layer', or 'machine'---or whatever the right nomenclature is---to apply these settings. Sorry for the long post, and thanks in advance for any advice! -- ~ # uname -a Linux localhost 2.6.36.2-WR3.0.2ax_standard #1 SMP PREEMPT Wed Oct 19 21:58:54 EEST 2011 armv7l armv7l armv7l GNU/Linux ODBP D1.0.1 (10.11.2011) ~ # cat /proc/cpuinfo Processor : ARMv7 Processor rev 0 (v7l) processor : 0 BogoMIPS: 1795.68 Features: swp half thumb fastmult vfp edsp vfpv3 vfpv3d16 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x1 CPU part: 0xc09 CPU revision: 0 Hardware: Tegra P852 SKU13 Revision: ... -- [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.36.2-WR3.0.2ax_standard (mmes@odbp-pines-build) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-67) ) #1 SMP PREEMPT Wed Oct 19 21:58:54 EEST 2011 [0.00] CPU: ARMv7 Processor [411fc090] revision 0 (ARMv7), cr=10c53c7f [0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [0.00] Machine: Tegra P852 SKU13 [0.00] Memory policy: ECC disabled, Data cache writealloc [0.00] PERCPU: Embedded 7 pages/cpu @80f6b000 s5600 r8192 d14880 u65536 [0.00] pcpu-alloc: s5600 r8192 d14880 u65536 alloc=16*4096 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 227328 [0.00] Kernel command line: mem=384M@0M nvmem=128M@384M mem=512M@512M vmalloc=384M video=tegrafb usbcore.old_scheme_first=1 smsc95xx.nv_bl_macid=:00:00:00:00:00:00 envsector=2c40 nvsku=000-0--000 SkuVer=0 ProdInfo=000-0--000 ProdVer=0 root=/dev/sda1 rw rootwait usbcore.old_scheme_first=1 mtdparts=tegra_nand:1024K@26752K(env),496000K@27776K(userspace) init=/bin/sh default.target=multi-user.target console=ttyS0,57600 [0.00] [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] allocated 5242880 bytes of page_cgroup [0.00] please try 'cgroup_disable=memory' option if you don't want memory cgroups [0.00] Memory: 384MB 512MB = 896MB total [0.00] Memory: 896796k/896796k available, 20708k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] DMA : 0xff00 - 0xffe0
