Re: [yocto] Migration from 1.7.1 to 1.8 - kernel-abiversion missing
> That is really odd. I'll be interested to hear how that happened. I just did a > test and it points to where I expect: > > [/home/bruc...poky/build]> bitbake -e core-image-minimal | grep > STAGING_KERNEL_BUILDDIR # $STAGING_KERNEL_BUILDDIR > STAGING_KERNEL_BUILDDIR="/home/bruce/poky/build/tmp/work- > shared/qemux86-64/kernel-build-artifacts" > So I experimented a bit more and found a minimal set of steps to reproduce the problem. Maybe that might give someone a clue as to what is happening and/or how to resolve it. Steps to reproduce: - clone Poky repository, checkout branch 'fido' - go to meta-yocto-bsp/conf/machine and copy beaglebone.conf to another file (I used astro.conf) - from poky repository do source oe-init-build-env into new build directory - edit conf/local.conf to set MACHINE ?= "astro" (use filename from second step) and DL_DIR (if present) - run bitbake core-image-minimal -> kernel-abiversion is missing, build fails - edit conf/local.conf, set MACHINE ?= "beaglebone" - run bitbake core-image-minimal -> image builds fine It stays the same if the copied config is in a custom BSP layer, some minor modifications are made, etc., but to eliminate complexity I just put that into the meta-yocto-bsp layer. What strikes me as really odd is that now the only thing changed between working and non-working configuration seems to be the filename of the machine configuration - what am I missing? How do I create a working machine configuration for Poky 1.8? (In 1.7.1 I just took some machine configuration from eldk, fiddled around with it a bit, put it into my BSP layer and never had any trouble with that.) Regards, Jan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Heads up
On Wed, Apr 29, 2015 at 7:18 AM, Gary Thomas wrote: > This is just a note that the recent upgrade of util-linux > to version 2.26.1 (from 2.25.2) was much more major than > the version change implies. The 'sfdisk' tool changed a > lot and will no longer be compatible with many scripts out > there that still use it. Can we document the needed differences and info for users ? may be it will handy in release notes too eventually when release time comes > > -- > > 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] [meta-raspberrypi] meta-ivi & meta-raspberrypi
@Mauro We can't wait to see the patches. :) @Oliver If you are working on this please assign yourself to http://redmine.gherzan.com/issues/19 On Wed, Apr 29, 2015 at 4:53 PM, Alex J Lennon < ajlen...@dynamicdevices.co.uk> wrote: > > > On 29/04/2015 16:34, Mauro Carvalho Chehab wrote: > > Em Wed, 29 Apr 2015 16:05:58 +0200 > > Alex J Lennon escreveu: > > > >> On 29/04/2015 15:30, Oliver wrote: > >>> Hello > >>> > >>> I have been working building together the meta-raspberrypi & the > meta-ivi layers. > >>> I have been stuck with configuration/compilation of weston(from > mata-ivi layer): > >>> > >>> 1) > >>> > >>> You can check the intial thread > http://lists.genivi.org/pipermail/genivi-meta-ivi/2015-April/000508.html > >>> > >>> > >>> egl provided by userlad is not detected as the *.pc files are not > deployed > >>> Someone has faced similar problems: > >>> > >>> > http://git.buildroot.net/buildroot/commit/?id=2282b93f4248a32de84805456efa352f69b28624 > >>> > >>> 2) > >>> With this I am able to reach the do_compile stage but there are errors > related to the undefined type > >>> > >>> PFNEGLQUERYWAYLANDBUFFERWL > >>> Hacked this one forcing the inclusion of :-S > >>> > >>> > >>> 3) > >>> At linking time the next trouble is: > >>> > >>> > /home/oliver/raspberry/build-rpi-ivi/tmp/sysroots/i686-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.1/ld: > cannot find -lwayland-egl > >>> > >>> IIRC this lib is provided by mesa-gl, but in my build, mesa is > configured(--disable-egl (is this ok being provided by userlad?)) which > might be the reason why libwayland-egl is not getting deployed in the image? > >>> > >>> Any correction to my statements or hint to go further would be > appreciated > >>> > >>> Best Regards & thanks for your time > >>> > >>> Oliver > >> Hi Oliver, > >> > >> I was looking at wayland/weston last year. I can't remember exactly > >> where I was at with it I am afraid, but I think I had it building and > >> have pushed some of the code I was playing with to GitHub > >> > >> I think this was related to the .pc issue > >> > >> > https://github.com/DynamicDevices/meta-raspberrypi/commit/491dd14585efdb52378a57fa6ddacb1f15065257 > >> > >> And this was what I was doing with weston. Looks like I was disabling > EGL. > >> > >> > https://github.com/DynamicDevices/meta-raspberrypi/commit/c657f69deb57035fc43319dd7d41745c17d7d6e1 > >> > >> Sorry I can't be more help but perhaps there's something in there that > >> might be of use. > > I was able to build weston/wayland with meta-raspberrypi, for > > the Tizen distro: > > > http://blogs.s-osg.org/bringing-tizen-to-a-raspberry-pi-2-near-you/ > > > > I had to apply a few patches to make it work on both Tizen and > > meta-raspberrypi. The forks are at: > > http://git.s-osg.org/ > > > > The current version there is actually disabling EGL. Enabling > > it seems to be possible, but we're still trying to make it work > > (it compiles fine, though, so I think we're close). > > > > Once done, my plan is to work on porting the patches back to > > meta-raspberrypi (and tizen-distro). > > > > > > Great news Mauro. If you need anybody to test out your patches, when > ready, please give me a shout. > > Cheers, Alex > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- *Andrei Gherzan* *e: **and...@gherzan.ro * *w: *www.gherzan.ro -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] virtual/libgles1
Hello Gary, I see that rpi doesn't provide gles1 in none of the graphics providers. So the only solution that I see for now is to have a new recipe (similar to mesa-gl) which will provide only gles1. Or, we can bbappend mesa to be used and provide only gles1 (this could be pretty hacky). Cheers! On Mon, Apr 13, 2015 at 2:12 PM, Gary Thomas wrote: > How can I get virtual/libgles1 on the RaspberryPi? libgles2 > is provided by "userland" but that package does not provide > libgles1. If I add a dependency on libgles1 (e.g. libva), > then there is a conflict which tries to install both mesa > and mesa-gl. > > Looking for ideas... > > Thanks > > -- > > Gary Thomas | Consulting for the > MLB Associates |Embedded world > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- *Andrei Gherzan* *e: **and...@gherzan.ro * *w: *www.gherzan.ro -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] gdk-pixbuf-native build error on YP 1.8 Fido
Hi all, First sorry, my English is poor I try to use on YP 1.8 Fido I add DISTRO_FEATURES_append = " directfb" because of I must use directfb When I build gdk-pixbuf-native, error occured below ~/works/Yocto/build/test$ bitbake gdk-pixbuf-native WARNING: Host distribution "Fedora-17" 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:04 Parsing of 871 .bb files complete (0 cached, 871 parsed). 1265 targets, 39 skipped, 0 masked, 0 errors. NOTE: Resolving any missing task queue dependencies ERROR: Nothing PROVIDES 'directfb-native' (but virtual:native:/home/B110141/works/git/poky-fido/meta/recipes-graphics/cairo/cairo_1.12.18.bb DEPENDS on or otherwise requires it). Close matches: db-native orc-native icu-native ERROR: Required build target 'gdk-pixbuf-native' has no buildable providers. Missing or unbuildable dependency chain was: ['gdk-pixbuf-native', 'harfbuzz-native', 'cairo-native', 'directfb-native'] Summary: There was 1 WARNING message shown. Summary: There were 2 ERROR messages shown, returning a non-zero exit code. I can not find why gdk-pixbuf-native have dependency harfbuzz-native On YP 1.7 Dizzy, gdk-pixbuf-native have not dependency harfbuzz-native Help me please Thanks = Wily Taekhyun Shin Research Engineer R&D Center Telechips Inc. Tel : + 82-2-3443-6792(Ext.390) Fax : + 82-2-6424-7793 Mobile : + 82-10-4376-5530 E-mail : ths...@telechips.com mailto:ksj...@telechips.com> = = This mail and attachments contain confidential information of Telechips Inc. which has its own authority. It is not allowed to disclose,transmit or use this confidential information to the third parties without the prior written consent of Telechips Inc. by any form or means. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents and destroy all copies of the original message. = -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Migration from 1.7.1 to 1.8 - kernel-abiversion missing
On 2015-04-30 3:14 AM, Schaumlöffel, Jan wrote: That is really odd. I'll be interested to hear how that happened. I just did a test and it points to where I expect: [/home/bruc...poky/build]> bitbake -e core-image-minimal | grep STAGING_KERNEL_BUILDDIR # $STAGING_KERNEL_BUILDDIR STAGING_KERNEL_BUILDDIR="/home/bruce/poky/build/tmp/work- shared/qemux86-64/kernel-build-artifacts" So I experimented a bit more and found a minimal set of steps to reproduce the problem. Maybe that might give someone a clue as to what is happening and/or how to resolve it. Steps to reproduce: - clone Poky repository, checkout branch 'fido' - go to meta-yocto-bsp/conf/machine and copy beaglebone.conf to another file (I used astro.conf) - from poky repository do source oe-init-build-env into new build directory - edit conf/local.conf to set MACHINE ?= "astro" (use filename from second step) and DL_DIR (if present) - run bitbake core-image-minimal -> kernel-abiversion is missing, build fails - edit conf/local.conf, set MACHINE ?= "beaglebone" - run bitbake core-image-minimal -> image builds fine It stays the same if the copied config is in a custom BSP layer, some minor modifications are made, etc., but to eliminate complexity I just put that into the meta-yocto-bsp layer. What strikes me as really odd is that now the only thing changed between working and non-working configuration seems to be the filename of the machine configuration - what am I missing? What kernel recipe is used when your machine is set to 'astro' ? Something custom ? Or have you added machine compatibility to another known kernel recipe ? The big difference that I see would be the kernel recipe, and some of the tasks not executing (and hence not generating the abiversion file). Bruce How do I create a working machine configuration for Poky 1.8? (In 1.7.1 I just took some machine configuration from eldk, fiddled around with it a bit, put it into my BSP layer and never had any trouble with that.) Regards, Jan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Migration from 1.7.1 to 1.8 - kernel-abiversion missing
> What kernel recipe is used when your machine is set to 'astro' ? > Something custom ? Or have you added machine compatibility to another > known kernel recipe ? How would I see which kernel recipe is used? I did not customize anything except for aforementioned steps, simply copied beaglebone.conf to astro.conf in the same directory. Also I did not touch any kernel recipes (kernel is built externally), maybe that's what's missing? Jan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Heads up
On 2015-04-30 01:45, Khem Raj wrote: On Wed, Apr 29, 2015 at 7:18 AM, Gary Thomas wrote: This is just a note that the recent upgrade of util-linux to version 2.26.1 (from 2.25.2) was much more major than the version change implies. The 'sfdisk' tool changed a lot and will no longer be compatible with many scripts out there that still use it. Can we document the needed differences and info for users ? may be it will handy in release notes too eventually when release time comes From the 2.26 release notes: This version provides a completely new sfdisk(8) command; the new version is based on libfdisk. If your use cases depend on sfdisk(8), then it is strongly recommended to be careful and re-test your scripts. The new version supports MBR and GPT disk labels (SGI and SUN are also supported but not well tested). The new version no longer supports some obscure MBR-specific command-line options nor legacy CHS addressing. What this means is that any script (there are a ton of them out there) that tries to create a label for a disk device using Cylinder-Head-Sectors style will have to be rewritten as the new sfdisk only does sector unit addressing. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] virtual/libgles1
On 2015-04-30 05:11, Andrei Gherzan wrote: Hello Gary, I see that rpi doesn't provide gles1 in none of the graphics providers. So the only solution that I see for now is to have a new recipe (similar to mesa-gl) which will provide only gles1. Or, we can bbappend mesa to be used and provide only gles1 (this could be pretty hacky). Fair enough. I'll take a look at this when I have a chance (no promises...) On Mon, Apr 13, 2015 at 2:12 PM, Gary Thomas mailto:g...@mlbassoc.com>> wrote: How can I get virtual/libgles1 on the RaspberryPi? libgles2 is provided by "userland" but that package does not provide libgles1. If I add a dependency on libgles1 (e.g. libva), then there is a conflict which tries to install both mesa and mesa-gl. Looking for ideas... -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Migration from 1.7.1 to 1.8 - kernel-abiversion missing
On 2015-04-30 08:27 AM, Schaumlöffel, Jan wrote: What kernel recipe is used when your machine is set to 'astro' ? Something custom ? Or have you added machine compatibility to another known kernel recipe ? How would I see which kernel recipe is used? This is where my brute force techniques probably break down. I just do a 'bitbake virtual/kernel' and you'll see it display which recipe is being built. If you haven't added compatibility for your new machine to any recipe, I'm betting that linux-dummy is used. I did not customize anything except for aforementioned steps, simply copied beaglebone.conf to astro.conf in the same directory. Also I did not touch any kernel recipes (kernel is built externally), maybe that's what's missing? It is plausible. But in theory, linux-dummy should still provide what you need (but since it doesn't build anything, there is no abi .. and no modules can be built against it) .. so the error isn't graceful. Bruce Jan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Replacing HOB in Build Appliance for YP 1.9
Hello, In 1.9 HOB is intended to be deprecated by Toaster functionality. This means that Build Appliance also must be changed. Since HOB is started automatically in BA in order to help users get started quickly with YP, I have the following proposal for updating BA in 1.9 and to replace HOB: * Update current BA implementation in order to support Toaster (maybe few patches needed to be included in the image in order to run Toaster) * If Toaster is enabled in BA then the user might be able to run Toaster from his host machine, or if BA is installed on a remote server, just access the server via HTTP. * this should be an easy solution to implement and maintain the BA functionality. There are solutions like Docker that were previously discussed, but my opinion is that first of all Docker is limited to Linux only. Secondly it will need much more QA effort (support at least 4 distros that YP currently supports) and more failure prone for specific Docker configurations. Regards, -- Alexandru Georgescu Yocto QA Engineer SSG/SSD Open Source Technology Center Romania -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Replacing HOB in Build Appliance for YP 1.9
+1 On 4/30/15, 9:06 AM, "Georgescu, Alexandru C" wrote: >Hello, >In 1.9 HOB is intended to be deprecated by Toaster functionality. This >means that Build Appliance also must be changed. Since HOB is started >automatically in BA in order to help users get started quickly with YP, I >have the following proposal for updating BA in 1.9 and to replace HOB: > > >* Update current BA implementation in order to support Toaster (maybe few >patches needed to be included in the image in order to run Toaster) >* If Toaster is enabled in BA then the user might be able to run Toaster >from his host machine, or if BA is installed on a remote server, just >access the server via HTTP. >* this should be an easy solution to implement and maintain the BA >functionality. > >There are solutions like Docker that were previously discussed, but my >opinion is that first of all Docker is limited to Linux only. Secondly it >will need much more QA effort (support at least 4 distros that YP >currently supports) and more failure prone for specific Docker >configurations. > >Regards, >-- >Alexandru Georgescu >Yocto QA Engineer >SSG/SSD Open Source Technology Center Romania > >-- >___ >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] [dizzy] shutdown custom image will not power off the processor
Hello, I don't know yet if this issue is bsp related or not, but I am trying to understand what is going on here. If anybody have any clue to help me solve my problem, I would appreciate. Using a custom image recipe, when I shutdown ( using the command ) my device will not power off. I see the message halt on the console but nothing is happening ... In daisy, the system were turning off correctly (with the same hardware) I don't know where to start to look at to solve this issue. I would like to hear your suggestions. Thank you Kris -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] fido: funny ipk behavior
Hi,
I have a simple recipe like this:
---
DESCRIPTION = "Simple helloworld application + git"
SECTION = "examples"
LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
SRCREV = "ecf1f0bc87960ef6b6d97c0385b44ce6ea5b2211"
SRC_URI =
"git:///home/genius/yocto-repos/simple-hello-world-git.git;protocol=file;branch=master"
S = "${WORKDIR}/git"
do_compile() {
${CC} simple-hello-world-git.c -o simple-hello-world-git
}
do_install() {
install -d ${D}${bindir}
install -m 0755 simple-hello-world-git ${D}${bindir}
}
---
If I bake the .ipk, copy it over to the target and try to install it
there it complains:
opkg install /tmp/simple-hello-world-git_1.0.1-r0_armv7a-vfp-neon.ipk
Installing simple-hello-world-git (1.0.1-r0) on root.
Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies
for simple-hello-world-git:
* libc6 (>= 2.21) *
* opkg_install_cmd: Cannot install package simple-hello-world-git.
---
If I include the package into my image it works, also if I just copy
over the executable (which is included in the package) it works.
scp
/home/genius/test/yocto-autobuilder/yocto-worker/custom-fido-vexpressa9-qemu-core-image-minimal/build/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/simple-hello-world-git/1.0.1-r0/git/simple-hello-world-git
root@192.168.7.2:/tmp
/tmp/simple-hello-world-git
Simple Hello world git!
Am I missing something?
I think this worked with dizzy.
Regards,
Robert..."In Pascal, when you foll with a pointer of a handle, you know
you're fooling with a pointer of a handle. In C, you could be fooling
around with anything. C is the ultimate language for computational
promiscuity." -- Owen Hartnett
My public pgp key is available,at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] fido: funny ipk behavior
Hi,
I have a simple recipe like this:
---
DESCRIPTION = "Simple helloworld application + git"
SECTION = "examples"
LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
SRCREV = "ecf1f0bc87960ef6b6d97c0385b44ce6ea5b2211"
SRC_URI =
"git:///home/genius/yocto-repos/simple-hello-world-git.git;protocol=file;branch=master"
S = "${WORKDIR}/git"
do_compile() {
${CC} simple-hello-world-git.c -o simple-hello-world-git
}
do_install() {
install -d ${D}${bindir}
install -m 0755 simple-hello-world-git ${D}${bindir}
}
---
If I bake the .ipk, copy it over to the target and try to install it
there opkg complains:
opkg install /tmp/simple-hello-world-git_1.0.1-r0_armv7a-vfp-neon.ipk
Installing simple-hello-world-git (1.0.1-r0) on root.
Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies
for simple-hello-world-git:
* libc6 (>= 2.21) *
* opkg_install_cmd: Cannot install package simple-hello-world-git.
---
If I include the package into my image it works, also if I just copy
over the executable (which is included in the package) it works.
scp
/home/genius/test/yocto-autobuilder/yocto-worker/custom-fido-vexpressa9-qemu-core-image-minimal/build/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/simple-hello-world-git/1.0.1-r0/git/simple-hello-world-git
root@192.168.7.2:/tmp
/tmp/simple-hello-world-git
Simple Hello world git!
Am I missing something?
I am pretty sure this worked with dizzy.
Regards,
Robert
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] fido: funny ipk behavior
On 2015-04-30 12:11, Robert Berger wrote:
Hi,
I have a simple recipe like this:
---
DESCRIPTION = "Simple helloworld application + git"
SECTION = "examples"
LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
SRCREV = "ecf1f0bc87960ef6b6d97c0385b44ce6ea5b2211"
SRC_URI =
"git:///home/genius/yocto-repos/simple-hello-world-git.git;protocol=file;branch=master"
S = "${WORKDIR}/git"
do_compile() {
${CC} simple-hello-world-git.c -o simple-hello-world-git
}
do_install() {
install -d ${D}${bindir}
install -m 0755 simple-hello-world-git ${D}${bindir}
}
---
If I bake the .ipk, copy it over to the target and try to install it
there it complains:
opkg install /tmp/simple-hello-world-git_1.0.1-r0_armv7a-vfp-neon.ipk
Installing simple-hello-world-git (1.0.1-r0) on root.
Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies
for simple-hello-world-git:
* libc6 (>= 2.21) *
* opkg_install_cmd: Cannot install package simple-hello-world-git.
On your target, what do you get from this?
# opkg list-installed libc6
---
If I include the package into my image it works, also if I just copy
over the executable (which is included in the package) it works.
scp
/home/genius/test/yocto-autobuilder/yocto-worker/custom-fido-vexpressa9-qemu-core-image-minimal/build/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/simple-hello-world-git/1.0.1-r0/git/simple-hello-world-git
root@192.168.7.2:/tmp
/tmp/simple-hello-world-git
Simple Hello world git!
Am I missing something?
I think this worked with dizzy.
Regards,
Robert..."In Pascal, when you foll with a pointer of a handle, you know
you're fooling with a pointer of a handle. In C, you could be fooling
around with anything. C is the ultimate language for computational
promiscuity." -- Owen Hartnett
My public pgp key is available,at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] fido: funny ipk behavior
Hi, On 04/30/2015 10:35 PM, Gary Thomas wrote: > > On your target, what do you get from this? > # opkg list-installed libc6 Nothing, since I forgot EXTRA_IMAGE_FEATURES_append = " package-management" Thanks, Robert..."it doesn't matter how beautiful your theory is, it doesn't matter how smart you are -- if it doesn't agree with experiment, it's wrong." - Richard P. Feynman My public pgp key is available,at: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] fido: funny ipk behavior
On 30 April 2015 at 21:30, Robert Berger wrote: > Nothing, since I forgot > > EXTRA_IMAGE_FEATURES_append = " package-management" > That will be it then - your image doesn't have a package database so any dependencies won't be able to be satisfied. Either force the installation or rebuild the image with package-management enabled. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] fido: funny ipk behavior
On Thu, 30 Apr 2015, Burton, Ross wrote: > > On 30 April 2015 at 21:30, Robert Berger > wrote: > Nothing, since I forgot > > EXTRA_IMAGE_FEATURES_append = " package-management" um ... i think you only need refer to EXTRA_IMAGE_FEATURES; with that variable, i believe the "_append" part is superfluous. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] fido: funny ipk behavior
On 2015-04-30 15:23, Robert P. J. Day wrote: On Thu, 30 Apr 2015, Burton, Ross wrote: On 30 April 2015 at 21:30, Robert Berger wrote: Nothing, since I forgot EXTRA_IMAGE_FEATURES_append = " package-management" um ... i think you only need refer to EXTRA_IMAGE_FEATURES; with that variable, i believe the "_append" part is superfluous. Unless it's already being set somewhere else - this seems like a safe way to make sure it gets set. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Release Candidate Build for yocto-1.7.2_rc3 now available.
-e A release candidate build for yocto-1.7.2_rc3 is now available at: http://autobuilder.yoctoproject.org/pub/releases/yocto-1.7.2_rc3 Please begin QA on this build as soon as possible. Build hash information: meta-intel : c39a4bf4450845fca6f1b26ccfc0db192a4567e8 meta-fsl-arm : db1571f40c375a398a8cdbb42de4c4f272ab0cd1 meta-minnow : 13a5f2ab84c7284647a3e067a33109c11dae0568 meta-qt3 : 3016129d90b7ac8517a5227d819f10ad417b5b45 meta-fsl-ppc : 5eeeb3ad74b72d904f805bc6e248e93e722b45c4 poky : 29812e61736a95f1de64b3e9ebbb9c646ebd28dd This is an automated message from The Yocto Project Autobuilder Git: git://git.yoctoproject.org/yocto-autobuilder Email: elizabeth.flana...@intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
