Re: [yocto] why was meta-dlna submodule history stripped out?
Hi Saul On 19/10/12 19:01, Saul Wold wrote: My apologies, I updated the MAINTAINER and README files. Thanks. (I am delighted Intel is finding Guacamayo useful, but the obliteration of the history makes it look as if the credit for this official Yocto layer goes to Intel; I am sure that was not intentional.) No this was not intentional, the combo-layer tool seems to do that. I used combo layer because we wanted to pull in the kvm changes so that this could be shown as a VM. Well, Poky uses the combo-layer and it maintains the commit history, even nicely injects the original hashes into the commit messages for reference. My basic gripe is that the 'Initial meta-dlna creation' commit squashes some 370+ commits, which represent somewhere in the region 500 man hours, bulk of it by sleep(5) ltd. I'd prefer if a public layer in a Linux Foundation collaborative project did not do away with that. In the first pass, there were mostly minor changes to cut this down to what was needed for the headless media server. This is the bit I don't get; it's not like oe-core contains just what is needed for poky-tiny, but I don't see you creating an oe-core fork for it. In fact this makes so little sense I doubt it was an engineering decision, perhaps someone somewhere forgot to take their NIH pills? :) As I moved to 1.3 there were more changes that I have made, you can see what's going on in the 1.3wip branch of meta-dlna. You are already getting bitten by the fact that you are forking meta-guacamayo. Upstream master has been updated to work with 1.3 some time back. It took fair amount of work to do (more than I'd have expected; lot of work to get things to build, and then quite a bit more to get them work). If you want some of those changes in meta-guacamayo please take them. Why is Intel so crap at working with upstream projects? I'll happily take any meaningful contributions (that excludes adding MACHINE_FEATURES='x86' into the layer.conf, though!), but please submit them. Right now I am fighting a dbus/rygel segfault. I am pretty sure I know which one, you are welcome to update to upstream meta-guacamayo, forks really are not a cost-efficient way of doing things. Kind regards, Tomas ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] why was meta-dlna submodule history stripped out?
On 20/10/12 13:16, Paul Eggleton wrote: On Friday 19 October 2012 11:01:09 Saul Wold wrote: Long term however I'd rather see the additional unique recipes in meta- guacamayo itself go into more official OE community layers. Ah, so there is an official community and an unoffical one, this community stuff is becoming rather difficult. ;-) I don't have any objections in principle, in fact you will see that number of the recipes in meta-guacamayo consists of a generic recipe and a guacamayo-specific bbappend. The main reason for maintaining most of the recipes in meta-guacamayo is precisely so that they would be maintained and updated in timely fashion and work with the stable release of Yocto. Guacamayo aims to facilitate that. Tomas ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] why was meta-dlna submodule history stripped out?
On Monday 22 October 2012 09:06:41 Tomas Frydrych wrote: On 20/10/12 13:16, Paul Eggleton wrote: On Friday 19 October 2012 11:01:09 Saul Wold wrote: Long term however I'd rather see the additional unique recipes in meta- guacamayo itself go into more official OE community layers. Ah, so there is an official community and an unoffical one, this community stuff is becoming rather difficult. ;-) I was referring to the meta-openembedded repository on openembedded.org. If people are looking for recipes they're going to be looking for them there first - surely it would be better that they'd find them there rather than just assuming they haven't been written and writing new ones themselves...? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] meta-intel: don't require commercial licenses for gstreamer-vaapi
Now that gstreamer-vaapi doesn't depend on ffmpeg, it can always be recommended
by the machine configuration.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta-cedartrail/conf/machine/cedartrail.conf |3 +--
meta-chiefriver/conf/machine/chiefriver.conf |3 +--
meta-crownbay/conf/machine/crownbay.conf |3 +--
meta-fri2/conf/machine/fri2.conf |3 +--
meta-sugarbay/conf/machine/sugarbay.conf |3 +--
meta-sys940x/conf/machine/sys940x.conf |3 +--
6 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/meta-cedartrail/conf/machine/cedartrail.conf
b/meta-cedartrail/conf/machine/cedartrail.conf
index ea50ea6..d8b6bc0 100644
--- a/meta-cedartrail/conf/machine/cedartrail.conf
+++ b/meta-cedartrail/conf/machine/cedartrail.conf
@@ -22,7 +22,6 @@ SYSLINUX_OPTS = serial 0 115200
SERIAL_CONSOLE = 115200 ttyS0
APPEND += console=ttyS0,115200 console=tty0
-VA_FEATURES = ${@bb.utils.contains(LICENSE_FLAGS_WHITELIST, \
- commercial, gst-va-intel va-intel, , d)}
+VA_FEATURES = gst-va-intel va-intel
MACHINE_EXTRA_RRECOMMENDS += ${VA_FEATURES}
diff --git a/meta-chiefriver/conf/machine/chiefriver.conf
b/meta-chiefriver/conf/machine/chiefriver.conf
index a9c8e5a..b8b8754 100644
--- a/meta-chiefriver/conf/machine/chiefriver.conf
+++ b/meta-chiefriver/conf/machine/chiefriver.conf
@@ -15,7 +15,6 @@ XSERVER ?= ${XSERVER_IA32_BASE} \
${XSERVER_IA32_I965} \
-VA_FEATURES = ${@bb.utils.contains(LICENSE_FLAGS_WHITELIST, \
- commercial, gst-va-intel va-intel, , d)}
+VA_FEATURES = gst-va-intel va-intel
MACHINE_EXTRA_RRECOMMENDS += ${VA_FEATURES} lms
diff --git a/meta-crownbay/conf/machine/crownbay.conf
b/meta-crownbay/conf/machine/crownbay.conf
index 72431de..d56ef64 100644
--- a/meta-crownbay/conf/machine/crownbay.conf
+++ b/meta-crownbay/conf/machine/crownbay.conf
@@ -23,7 +23,6 @@ PREFERRED_VERSION_xf86-input-evdev ?= 2.6.0
APPEND += video=vesafb vga=0x318 vmalloc=256MB
-VA_FEATURES = ${@bb.utils.contains(LICENSE_FLAGS_WHITELIST, \
- commercial, gst-va-intel va-intel, va-intel, d)}
+VA_FEATURES = gst-va-intel va-intel
MACHINE_EXTRA_RRECOMMENDS += ${VA_FEATURES}
diff --git a/meta-fri2/conf/machine/fri2.conf b/meta-fri2/conf/machine/fri2.conf
index dff11a8..587b976 100644
--- a/meta-fri2/conf/machine/fri2.conf
+++ b/meta-fri2/conf/machine/fri2.conf
@@ -8,8 +8,7 @@ require conf/machine/include/tune-atom.inc
require conf/machine/include/ia32-base.inc
require conf/machine/include/meta-intel.inc
-VA_FEATURES = ${@bb.utils.contains(LICENSE_FLAGS_WHITELIST, \
- commercial, gst-va-intel va-intel, va-intel, d)}
+VA_FEATURES = gst-va-intel va-intel
MACHINE_FEATURES += wifi 3g pcbios efi va-impl-mixvideo
MACHINE_EXTRA_RRECOMMENDS += linux-firmware-iwlwifi-6000g2a-5 ${VA_FEATURES}
diff --git a/meta-sugarbay/conf/machine/sugarbay.conf
b/meta-sugarbay/conf/machine/sugarbay.conf
index 17cc15c..1d0e68d 100644
--- a/meta-sugarbay/conf/machine/sugarbay.conf
+++ b/meta-sugarbay/conf/machine/sugarbay.conf
@@ -16,7 +16,6 @@ XSERVER ?= ${XSERVER_IA32_BASE} \
${XSERVER_IA32_I965} \
-VA_FEATURES = ${@bb.utils.contains(LICENSE_FLAGS_WHITELIST, \
- commercial, gst-va-intel va-intel, , d)}
+VA_FEATURES = gst-va-intel va-intel
MACHINE_EXTRA_RRECOMMENDS += ${VA_FEATURES}
diff --git a/meta-sys940x/conf/machine/sys940x.conf
b/meta-sys940x/conf/machine/sys940x.conf
index bdd655f..eefca59 100644
--- a/meta-sys940x/conf/machine/sys940x.conf
+++ b/meta-sys940x/conf/machine/sys940x.conf
@@ -26,7 +26,6 @@ PREFERRED_VERSION_emgd-driver-bin ?= 1.14
SERIAL_CONSOLE = 115200 ttyS0
APPEND += console=ttyS0,115200 console=tty0
-VA_FEATURES = ${@bb.utils.contains(LICENSE_FLAGS_WHITELIST, \
- commercial, gst-va-intel va-intel, va-intel, d)}
+VA_FEATURES = gst-va-intel va-intel
MACHINE_EXTRA_RRECOMMENDS += ${VA_FEATURES}
--
1.7.10
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Cedar Trail and gst-vaapi fixes
On 19 October 2012 21:08, Tom Zanussi tom.zanu...@intel.com wrote: I pulled the first two patches into meta-intel/master, but left the third behind - we still need the commercial license since the gst-ffmpeg requires it, and even then we still want to keep the VA_FEATURES so users can just set it to to not include video acceleration. I've restored VA_FEATURES but as gst-ffmpeg is a only-if-commercial rdependency of gst-va-intel-general (and not gst-vaapi with the patches you merged), I don't see why the commercial checks need to be anywhere but the rdepends of gst-va-intel-general. (V2 just sent) Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] AUTOREV problems
Hello All,
I've been having some serious problems trying to get my image to rebuild
recipes when their upstream repositories have changed. I have SRCREV =
${AUTOREV} in my recipe and in bitbake -e I see these 2 lines:
# SRCREV=${AUTOREV}
SRCREV=AUTOINC
I've found BB_SRCREV_POLICY and I've set that explicitly to clear, even
though that seems to be the default. Auto didn't seem to work, even though
it looks like it should from the code.
When I try rebuilding my recipe, it seems to find that everything is cached
and doesn't even attempt the fetch, even though I know the repository has
changed (that's the reason I want to rebuild :)). I've tried whacking
tmp/cache/*, but that didn't help. I tried whacking the stamp for
do_fetch. That didn't help unless I explicitly built using the fetch
command, then it at least appeared to fetch. However, when I tried to
build the image after that, it didn't try to rebuild the recipe that had
just fetched.
The only way I could get it to rebuild was to cleansstate on the recipe and
then rebuild the image. I assume this isn't the way it should be working.
1. What is the expected operation of bitbake builds for recipes using
autorev?
2. How can I get my autorev recipes to rebuild when their repositories
change?
3. If this is working for everyone else, how can I find what I have
screwed up? :)
Thanks,
Seth
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] AUTOREV problems
Hi, On 22/10/12 12:56, Seth Bollinger wrote: 1. What is the expected operation of bitbake builds for recipes using autorev? It should just work (and FWIW, it's working here). 2. How can I get my autorev recipes to rebuild when their repositories change? 3. If this is working for everyone else, how can I find what I have screwed up? :) It's hard to say without seeing the recipe in question. Tomas ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] AUTOREV problems
Seth,
Like Tomas said, it's hard to say for sure without seeing the recipe in
question, but I know one way this could happen: AUTOREV, by itself, does
not permute your hash. It ends up just resolving to the string AUTOINC
every time. You *also *need the SRCPV variable somewhere in your recipe,
as it will contain the real revision the was retrieved from version
control. I believe the normal way to use SRCPV is as follows:
PV = vcs-version-${SRCPV}
For example:
PV = svn-1.0.0-${SRCPV}
If you aren't using SRCPV, your hash won't permute, and you won't rebuild.
The reason for this behavior isn't obvious off-hand, but I suspect it's so
you can set AUTOREV for a specific package in local.conf and not force half
the world to get reparsed every time a revision updates.
Kind regards,
Jerrod
On Mon, Oct 22, 2012 at 7:56 AM, Seth Bollinger seth.b...@gmail.com wrote:
Hello All,
I've been having some serious problems trying to get my image to rebuild
recipes when their upstream repositories have changed. I have SRCREV =
${AUTOREV} in my recipe and in bitbake -e I see these 2 lines:
# SRCREV=${AUTOREV}
SRCREV=AUTOINC
I've found BB_SRCREV_POLICY and I've set that explicitly to clear, even
though that seems to be the default. Auto didn't seem to work, even though
it looks like it should from the code.
When I try rebuilding my recipe, it seems to find that everything is cached
and doesn't even attempt the fetch, even though I know the repository has
changed (that's the reason I want to rebuild :)). I've tried whacking
tmp/cache/*, but that didn't help. I tried whacking the stamp for
do_fetch. That didn't help unless I explicitly built using the fetch
command, then it at least appeared to fetch. However, when I tried to
build the image after that, it didn't try to rebuild the recipe that had
just fetched.
The only way I could get it to rebuild was to cleansstate on the recipe and
then rebuild the image. I assume this isn't the way it should be working.
1. What is the expected operation of bitbake builds for recipes using
autorev?
2. How can I get my autorev recipes to rebuild when their repositories
change?
3. If this is working for everyone else, how can I find what I have
screwed up? :)
Thanks,
Seth
___
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] AUTOREV problems
Correction: I'm wrong on the standard for PV. The standard (after looking
through some BB files) appears to be this:
PV = version number+vcs${SRCPV}
On Mon, Oct 22, 2012 at 8:46 AM, Jerrod Peach pea...@lexmark.com wrote:
Seth,
Like Tomas said, it's hard to say for sure without seeing the recipe in
question, but I know one way this could happen: AUTOREV, by itself, does
not permute your hash. It ends up just resolving to the string AUTOINC
every time. You *also *need the SRCPV variable somewhere in your recipe,
as it will contain the real revision the was retrieved from version
control. I believe the normal way to use SRCPV is as follows:
PV = vcs-version-${SRCPV}
For example:
PV = svn-1.0.0-${SRCPV}
If you aren't using SRCPV, your hash won't permute, and you won't rebuild.
The reason for this behavior isn't obvious off-hand, but I suspect it's so
you can set AUTOREV for a specific package in local.conf and not force half
the world to get reparsed every time a revision updates.
Kind regards,
Jerrod
On Mon, Oct 22, 2012 at 7:56 AM, Seth Bollinger seth.b...@gmail.comwrote:
Hello All,
I've been having some serious problems trying to get my image to rebuild
recipes when their upstream repositories have changed. I have SRCREV =
${AUTOREV} in my recipe and in bitbake -e I see these 2 lines:
# SRCREV=${AUTOREV}
SRCREV=AUTOINC
I've found BB_SRCREV_POLICY and I've set that explicitly to clear, even
though that seems to be the default. Auto didn't seem to work, even
though
it looks like it should from the code.
When I try rebuilding my recipe, it seems to find that everything is
cached
and doesn't even attempt the fetch, even though I know the repository has
changed (that's the reason I want to rebuild :)). I've tried whacking
tmp/cache/*, but that didn't help. I tried whacking the stamp for
do_fetch. That didn't help unless I explicitly built using the fetch
command, then it at least appeared to fetch. However, when I tried to
build the image after that, it didn't try to rebuild the recipe that had
just fetched.
The only way I could get it to rebuild was to cleansstate on the recipe
and
then rebuild the image. I assume this isn't the way it should be working.
1. What is the expected operation of bitbake builds for recipes using
autorev?
2. How can I get my autorev recipes to rebuild when their repositories
change?
3. If this is working for everyone else, how can I find what I have
screwed up? :)
Thanks,
Seth
___
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] [PATCH 1/3] [meta-intel] meta-intel/common:Add a new recipe for Zlib qat_mem Module.
On Sun, 2012-10-21 at 23:03 -0500, Tom Zanussi wrote: On Sun, 2012-10-21 at 22:15 -0500, Bodke, Kishore K wrote: -Original Message- From: Zanussi, Tom Sent: Friday, October 19, 2012 11:49 AM To: Bodke, Kishore K Cc: Kamble, Nitin A; yocto@yoctoproject.org Subject: Re: [PATCH 1/3] [meta-intel] meta-intel/common:Add a new recipe for Zlib qat_mem Module. On Fri, 2012-10-19 at 13:40 -0500, Bodke, Kishore K wrote: -Original Message- From: Zanussi, Tom Sent: Friday, October 19, 2012 11:35 AM To: Bodke, Kishore K Cc: Kamble, Nitin A; yocto@yoctoproject.org Subject: Re: [PATCH 1/3] [meta-intel] meta-intel/common:Add a new recipe for Zlib qat_mem Module. Hi Kishore, I've built these and they look ok as far as that goes. But I'm wondering, which kernel did you test with and which kernel(s) are these modules designed for i.e. will they work with all the kernels supported for 1.3? Hi Tom, I have tested them for 3.4 Kernel for Yocto, since for Crystal Forest we only have 3.4 for now. Apart from that, it should work with all the kernel versions. I have tested 3.0 and 3.5 on Fedora. OK, for something in common, we have to think about someone using them with any yocto kernel, not just 3.4. Since you're saying they work with 3.0, 3.4 and 3.5, I guess there's not too much risk that they'll break with 3.2. If that's not the case, you should probably restrict them to your BSP (but we don't want multiple copies) either. The best thing would be to move them into the linux-yocto kernel(s) they have been tested with - that way users know those features work and are safe to use in their BSPs. These modules just need the configured kernel for them to build with. It is not specific to particular kernel version. Also, every time the Kernel version moves, this whole set needs to be moved too. Instead have it in the BSP and we do not have to run around moving around with the different kernels. Instead it is nice to have one copy in common. Hmm, I'm not able to build them with linux-yocto-3.2: OK, not sure what happened here, but as a test I tried building them for jasperforest using a 3.2 kernel and the modules built without problem. So, pulled into meta-intel/master. Tom [trz@empanada build]$ bitbake core-image-qat Loading cache: 100% |##| ETA: 00:00:00 Loaded 1156 entries from dependency cache. Build Configuration: BB_VERSION= 1.16.0 TARGET_ARCH = x86_64 TARGET_OS = linux MACHINE = crystalforest-shumway DISTRO= poky DISTRO_VERSION= 1.3 TUNE_FEATURES = m64 TARGET_FPU= meta meta-yocto meta-yocto-bsp= danny0:4cce3e4abab65116ca968174e59a049438ec7385 meta-intel meta-crystalforest = master0:c94e89507fbab050efa2e326ec92e63fb9dc07a6 NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks NOTE: validating kernel configuration WARNING: Can't find any BSP hardware or required configuration fragments. WARNING: Looked at meta/cfg/standard/crystalforest/hdw_frags.txt and meta/cfg/standard/crystalforest/required_frags.txt in directory: meta/cfg/standard/crystalforest WARNING: QA Issue: Architecture did not match (62 to 2) on /work/x86_64-poky-linux/canterbury-corpus-1.0-r0/packages-split/canterbury-corpus/lib/firmware/sum ERROR: Function failed: do_compile (see /home/trz/yocto/isg-test/build/tmp/work/crystalforest_shumway-poky-linux/openssl-qat-module-1.0.1-r0/temp/log.do_compile.19389 for further information) ERROR: Logfile of failure stored in: /home/trz/yocto/isg-test/build/tmp/work/crystalforest_shumway-poky-linux/openssl-qat-module-1.0.1-r0/temp/log.do_compile.19389 Log data follows: | DEBUG: Executing shell function do_compile | NOTE: make -j 16 -e MAKEFLAGS= KERNEL_CC=x86_64-poky-linux-gcc | x86_64-poky-linux-gcc-m64 --sysroot=/home/trz/yocto/isg-test/build/tmp/sysroots/crystalforest-shumway -g -o qat_mem_test qat_mem_test.c | make -C /home/trz/yocto/isg-test/build/tmp/sysroots/crystalforest-shumway/usr/src/kernel SUBDIRS=/home/trz/yocto/isg-test/build/tmp/work/crystalforest_shumway-poky-linux/openssl-qat-module-1.0.1-r0/openssl-1.0.1/engines/qat_engine/qat_mem modules | make[1]: Entering directory `/home/trz/yocto/isg-test/build/tmp/sysroots/crystalforest-shumway/usr/src/kernel' | CC [M] /home/trz/yocto/isg-test/build/tmp/work/crystalforest_shumway-poky-linux/openssl-qat-module-1.0.1-r0/openssl-1.0.1/engines/qat_engine/qat_mem/qat_mem.o | Building modules, stage 2. | MODPOST 1 modules | CC
[yocto] Agenda: Yocto Project Technical Team Meeting - Tuesday, October 23, 2012 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US Canada).
Agenda: * Opens collection - 5 min (Song) * Yocto 1.3 release readiness - 20 min (Song/team) https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status#Milestone_5_.281.3_release.29 * SWAT team rotation: Saul - Nitin * Opens - 10 min * Team Sharing - 20 min -Original Appointment- We encourage people attending the meeting to logon the Yocto IRC chancel during the meeting (optional): Yocto IRC: http://webchat.freenode.net/?channels=#yocto IRC Tutorial: http://www.irchelp.org/irchelp/irctutorial.html Conference details Conference name: Yocto Technical Team Conference date/start time: Tue Jun 26, 2012 at 10:00 AM Central Daylight Time Participants: 30 Duration: 60 minutes Participant passcode: 76994298 Dial-in number: 1.972.995. US Toll Free number: 1.877.561.6828 BlackBerry users, click this link to join your conference as a participant: 1.972.995.x76994298# Depending on where you are dialing from, either your BlackBerry will pause and enter the passcode automatically or you will be prompted to click again to dial the passcode. Local and Global Access Numbers Country Dial-in number Australia: 1800 636 843 Czech Republic: 242 430 350 China (Beijing): From office dial 8-995 or 8784277 Beijing Out of Office dial 5878 4277 China (Shanghai): From office dial 8-995 or 3073322 Shanghai Out of Office dial 2307 3322 China (Shenzen): From office dial 8-995 or 6007877 Shenzen Out of Office dial 2600 7877 China (Other Cities): From IP phone dial 8-995 Other cities - Non IP phone dial 021-23073322 Denmark: 8060 1400 Finland: 09 41333477 France: 0497 275888 Germany: 08161 803232 Holland: 030 2417490 India: BSNL subscribers use 1800 425 9996 (Toll Free) Airtel subscribers use 0008 009 861 212 (Toll Free) From TI Campus use 8995 Others use 2509 9555 (Landline within Bangalore) or 80 2509 9555 (Outside Bangalore) Israel: 09 790 6715 Italy: 039 69061234 (039 is local city code not country code) Japan: From TI Campus use 8 995 Outside TI use 03 4331 3777 Malaysia: From IP phone dial 2643799 From Kuala Lumpur dial 4264 3799 Outside Kuala Lumpur dial (03)4264 3799 Norway: 2 295 8744 Philippines: From Baguio City use 4471177 From Metro Manila area use 8702477 Singapore: From IP phone dial 3894777 Outside TI use 6389 4777 South Korea: From IP phone dial 5606998 From Seoul dial 5606998 Outside Seoul dial (02)5606998 Sweden: 08 58755577 Taiwan: From IP phone dial 1363 From Taipei dial 2241 1363 Outside Taipei dial (02)2241 1363 Turkey: Landline Only dial 0811 288 0001 then enter 877 633 1123 UK: 01604 663003 US: 972 995 or 1877 561 6828 Recurring conferences First scheduled conference: Tue Jun 26, 2012 Recurrence frequency: Weekly - Every 1 week(s) on Tuesday Recurrence ends: End on Fri Jun 21, 2013, 10:40 AM CDT ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ERROR: Function failed: do_rootfs, poky commit id 8ce23f569584f195391bc5c68a780e1bf54e4360
Hi, On Oct 23, 2012, at 12:22 AM, Elvis Dowson elvis.dow...@gmail.com wrote: | Configuring sysvinit. | Collected errors: | * preinst_configure: Aborting installation of base-passwd. | * opkg_install_cmd: Cannot install package packagegroup-core-boot. | ERROR: Function failed: do_rootfs (see /tool/yocto/poky/build/tmp/work/zynq_zc702-poky-linux-gnueabi/core-image-minimal-1.0-r0/temp/log.do_rootfs.30138 for further information) ERROR: Task 7 (/tool/yocto/poky/meta/recipes-core/images/core-image-minimal.bb, do_rootfs) failed with exit code '1' NOTE: Tasks Summary: Attempted 1395 tasks of which 227 didn't need to be rerun and 1 failed. No currently running tasks (1395 of 1396) The build appears to be failing because it cannot install packagegroup-core-boot. Has something changed recently in poky/master, that might be causing this? Best regards, Elvis Dowson___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
