[yocto] Howto add TIPC-support into kernel?
Hi! I'm writing a recipe for a piece of software that requires TIPC support in the kernel. I've tried to figure out a way to accomplish this within my bb-file, but with no success. Is there a way to do such thing with Yocto, currently I run 'bitbake -c menuconfig linux-yocto' (or is it yocto-linux, can't recall) and then I add 'kernel-modules' to IMAGE_INSTALL_append in my 'local.conf'-file? I would like to have this dependency some-how contained within my recipe. Thanks! Best regards, Jonas Jonsson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 00/62] denzil pull request 2
On Mon, 2012-09-24 at 17:29 -0700, Scott Garman wrote:
The following changes since commit 65ffa7395055f7e012cb973f63f92380828eed0d:
yocto-bsp: use base branches for qemu 'newbranch' case (2012-08-21 11:35:22
+0100)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib sgarman/denzil-next-pull2
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=sgarman/denzil-next-pull2
Bogdan Marinescu (1):
Save proxy settings
Bruce Ashfield (4):
linux-yocto: allow do_validate_branches to handle all branches
kernel-yocto: set master branch to a defined SRCREV
kernel: save $kerndir/tools and $kerndir/lib from pruning
kernel.bbclass: add non-santized kernel provides
Constantin Musca (1):
pulseaudio: upgrade to 2.1
Cristian Iorga (4):
gst-plugin-bluetooth: update to ver. 4.101
bluez4: update to ver. 4.101
pulseaudio: upgrade to 2.0
libcanberra: upgrade to 0.29
Darren Hart (1):
kernel: Add kernel headers to kernel-dev package
Denys Dmytriyenko (1):
pulseaudio: fix typo in the patch name, pulseaudo - pulseaudio
Dongxiao Xu (1):
bluez-hcidump: upgrade to version 2.4
Franklin S Cooper Jr (1):
psplash: LIC_CHKSUM Tweak
Franklin S. Cooper Jr (1):
u-boot: Use fw_env.config if avaliable
Jeff Polk (1):
recipes-core/eglibc-2.13: Patch for locale-base-tt-ru packaging
Jonas Danielsson (1):
bluez4: make alsa support conditional upon DISTRO_FEATURES
Kang Kai (1):
ltp_20120104: add rdepends
Khem Raj (3):
kernel.bbclass: Dont package kxgettext.o
libatomics-ops: Make it build for SH4
pulseaudio: Always enable NLS
Koen Kooi (2):
man: fix RDEPENDS and reformat recipe
man: make man actually work by installing custom man.config
Marcin Juszkiewicz (1):
libpam: disable NIS to not link with libtirpc when it is available
Martin Jansa (5):
package.bbclass: fix TypeError in runstrip
opkg-utils: bump SRCREV for Packages cache fix and other fixes
opkg-utils: bump SRCREV
kernel.bbclass: pass KERNEL_VERSION to depmod calls in postinst
pulseaudio: fix pulseaudio-server RDEPENDS
Matthew McClintock (9):
dbus.inc: disable selinux for native builds
glib.inc: disable selinux for native builds
eglibc/gcc: add patches to fix eglibc 2.15 build
poky.conf: add distros that work correctly
distutils.bbclass: fix libdir for 64-bit python modules built with
distutils
distutils.bblass: change order of args to install step
eglibc_2.15: make patch only for Freescale machines
valgrind_3.7.0.bb: fix missing leading space on _append
sysvinit-inittab_2.88dsf.bb: only run serial checks at boot if we
have items to check
Paul Eggleton (4):
classes/mirrors: remove bogus gnutls mirror
dhcp: remove dependency of dev/staticdev packages on main package
bitbake: hob: ensure error message text is properly escaped
bitbake: hob: format error messages properly
Radu Moisan (1):
dbus: include dbus-launch in the main dbus package
Richard Purdie (5):
distutils/steuptools: Fix files layout and unbreak builds
opkg-utils: UPdate to version with python 2.6 fix
autotools.bbclass: Add functionality to force a clean of ${B} when
reconfiguring (and ${S} != ${B})
dbus: Ensure dbus-nativesdk doesn't RPROVIDE dbus-x11
texi2html: Fix perl location on recent distros
Ross Burton (1):
pulseaudio: remove ConsoleKit dependency
Saul Wold (7):
build-appliance-image: Update SRCREV to Denzil 1.2.1
build-appliance-image: Add vmx* files and build zip file
build-appliance: add zip-native, which is needed to build the final
zip bundle
python-pygtk: Upgrade to 2.24
kernel: Fix packaging issue
bluez4: fix packaging issue after update
pulseaudio: disable tcpwrap by default
Scott Garman (2):
relocatable.bbclass: Account for case when ORIGIN is in RPATH
kernel.bbclass: put perf .debug dir in -dbg package
Valentin Popa (2):
build-appliance-image: rename from self-hosted-image
xz: updated to version 5.1.1alpha
Xin Ouyang (1):
libatomics-ops: update to the latest version 7.2
Zhenhua Luo (1):
valgrind: fix debug info reading error when do memcheck on ppc
targets
These got merged to the denzil branch, thanks.
Richard
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Cannot do atom-pc build with meta-cedartrail
On 2012-09-29 23:50, Ross Burton wrote: On Thursday, 27 September 2012 at 18:07, Tom Zanussi wrote: Yeah, looks like the other SRC_URIs do that, but it's missing from that SRC_URI - I just pushed a fix for this one to meta-intel/master. Thanks Tom, I've been frequently flipping between atom-pc and cedartrail and this was getting annoying. Ross Unfortunately this change breaks SRC_URI appends, discarded or overwritten; e.g. adding meta-tlk brings no change to SRC_URI. -- Mihai Lindner ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Cannot do atom-pc build with meta-cedartrail
On Tue, 2012-10-02 at 18:00 +0300, Mihai Lindner wrote: On 2012-09-29 23:50, Ross Burton wrote: On Thursday, 27 September 2012 at 18:07, Tom Zanussi wrote: Yeah, looks like the other SRC_URIs do that, but it's missing from that SRC_URI - I just pushed a fix for this one to meta-intel/master. Thanks Tom, I've been frequently flipping between atom-pc and cedartrail and this was getting annoying. Ross Unfortunately this change breaks SRC_URI appends, discarded or overwritten; e.g. adding meta-tlk brings no change to SRC_URI. It shouldn't though, since the application of the meta-tlk SRC_URI bbappend should follow the SRC_URI assignment in the cedartrail bbappend. On the other hand, the layer priorities don't seem to be right - meta-cedartrail is supposed to have a priority of 6, but it doesn't actually seem to: BBFILE_PRIORITY_cedartrail = 6 [trz@empanada build]$ bitbake-layers show_layers layer path priority == meta /home/trz/yocto/crownbay-test/meta5 meta-yocto/home/trz/yocto/crownbay-test/meta-yocto 5 meta-yocto-bsp/home/trz/yocto/crownbay-test/meta-yocto-bsp 5 meta-intel/home/trz/yocto/crownbay-test/meta-intel 5 meta-cedartrail /home/trz/yocto/crownbay-test/meta-intel/meta-cedartrail 5 meta-tlk /home/trz/yocto/crownbay-test/meta-intel/meta-tlk 5 On the other hand, meta-tlk does follow meta-cedatrail in the parse order so should append to the SRC_URI... Tom ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Tftp Server Problem P1021rdb
Hello, Ich ve got to install the TFTP-Server on the Linux Virtual Machine(Ubuntu 10.04) : sudo apt-get install xinetd tftpd-hpa tftp sudo vim /etc/default/tftpd-hpa #defaults for tftp-hpa RUN_DAEMON=yes OPTIONS=-l -s /var/lib/tftpboot Then, I set up the TFTP Folder: sudo mkdir /tftpboot sudo chmod -R 777 /tftpboot sudo chown -R nobody /tftpboot Straight after that, I startet the server: sudo /etc/init.d/tftpd-hpa start The problem is that I cant get any file from the server to the device.! The problem remains when I try to get a file to my Windows Host (Window 7) T T T T T T retry count exceed... I tried to get a file by using another terminal within the same linux virtual machine tftp VirtualMachineIP get RunThis.sh Timeout It didnt work out Alternatively, I configured the xinetd Tftp script : sudo vim /etc/xinetd/tftp Then I stopped tftpd-hpa. then startes xinetd (sudo service xinetd start) All that didnt work. Any Idea what I can do? Thank in advance tftp Description: Binary data ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How do you release distros produced with Yocto? How should I?
Hi, On 02/10/12 17:43, Jerrod Peach wrote: I'm also starting to think there might be a better way to handle this with Yocto's concept of distros (perhaps have a distro for printer X, and a different one for printer Y, each pointing at versions of code that are good for the respective printer), but my research so far hasn't given me enough information on distros to know if this is a reasonable approach. (I've poked through some of the documentation and the mailing list archives.) So, what do you all do for releasing code? Does anyone have a situation similar to mine? (I can't imagine I'm unique, but maybe I'm more special than I thought.) Even if you don't have a situation like mine, what would you suggest I do for releasing code for our printers? Sounds to me like your situation implies a single distro + multiple machines, one for each distinct printer model; you can then specify revisions on per-machine basis. Whether you specify the machine specific revisions in the bb files, or whether you pull it together into an include file is a matter of taste more than anything else I suspect, as long as everyone knows what the deal is. But I'd advise not to specify package revisions local.conf, that's really for the developer/user to tweak, and it should not be stored in vcs, doings so just causes pain. I use the unified include file in Guacamayo for the packages that we maintain; this is for convenience, as during the development cycle I use AUTOREV for these packages, but for an actual release specify the revisions explicitly and having them all in one place makes this easier to do and not forget anything. See, https://github.com/Guacamayo/meta-guacamayo/tree/master/meta-guacamayo/conf/ for how we got it set up. Tomas ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/1] [meta-intel] meta-crystalforest: Create a custom build Image recipe.
From: Kishore Bodke kishore.k.bo...@intel.com To build with the corpus files recipes, create a customized recipe to install them into the Image. Signed-off-by: Kishore Bodke kishore.k.bo...@intel.com --- .../recipes-qat-image/images/core-image-qat-sdk.bb | 16 .../recipes-qat-image/images/core-image-qat.bb | 16 2 files changed, 32 insertions(+) create mode 100644 meta-crystalforest/recipes-qat-image/images/core-image-qat-sdk.bb create mode 100644 meta-crystalforest/recipes-qat-image/images/core-image-qat.bb diff --git a/meta-crystalforest/recipes-qat-image/images/core-image-qat-sdk.bb b/meta-crystalforest/recipes-qat-image/images/core-image-qat-sdk.bb new file mode 100644 index 000..27feb0d --- /dev/null +++ b/meta-crystalforest/recipes-qat-image/images/core-image-qat-sdk.bb @@ -0,0 +1,16 @@ +# Copyright (C) 2012 Intel Corporation. +# Author: Kishore Bodke +# kishore.k.bo...@intel.com +# + +require recipes-sato/images/core-image-sato-sdk.bb + +IMAGE_INSTALL += \ + calgary-corpus \ + canterbury-corpus \ + silesia-corpus \ + + +LICENSE = MIT + +PR = r0 diff --git a/meta-crystalforest/recipes-qat-image/images/core-image-qat.bb b/meta-crystalforest/recipes-qat-image/images/core-image-qat.bb new file mode 100644 index 000..7c61ec6 --- /dev/null +++ b/meta-crystalforest/recipes-qat-image/images/core-image-qat.bb @@ -0,0 +1,16 @@ +# Copyright (C) 2012 Intel Corporation. +# Author: Kishore Bodke +# kishore.k.bo...@intel.com +# + +require recipes-sato/images/core-image-sato.bb + +IMAGE_INSTALL += \ + calgary-corpus \ + canterbury-corpus \ + silesia-corpus \ + + +LICENSE = MIT + +PR = r0 -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/1][meta-intel] Add a custom Image recipe
From: Kishore Bodke kishore.k.bo...@intel.com This patch adds the custom build Image recipe to install all the corpus files into the image. Please pull them into meta-intel/master. Thanks Kishore. The following changes since commit 50ac6e8785c167ea4aa4601fd690ef783151853d: meta-intel: use FILESEXTRAPATHS for xserver-xf86-config bbappends (2012-10-02 11:30:47 -0500) are available in the git repository at: git://git.pokylinux.org/meta-intel-contrib Kishore/CRF-Image http://git.pokylinux.org/cgit.cgi/meta-intel-contrib/log/?h=Kishore/CRF-Image Kishore Bodke (1): meta-crystalforest: Create a custom build Image recipe. .../recipes-qat-image/images/core-image-qat-sdk.bb | 16 .../recipes-qat-image/images/core-image-qat.bb | 16 2 files changed, 32 insertions(+) create mode 100644 meta-crystalforest/recipes-qat-image/images/core-image-qat-sdk.bb create mode 100644 meta-crystalforest/recipes-qat-image/images/core-image-qat.bb -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How do you release distros produced with Yocto? How should I?
Tomas, Sounds to me like your situation implies a single distro + multiple machines, one for each distinct printer model; you can then specify revisions on per-machine basis. I don't think that's actually what we want. The architecture of each machine will be the same. That is, one ASIC will generally be on all the printers in a family of products. I think I actually have one machine + multiple distros. Or, should I really be counting each different printer as its own machine? Whether you specify the machine specific revisions in the bb files, or whether you pull it together into an include file is a matter of taste more than anything else I suspect, as long as everyone knows what the deal is. But I'd advise not to specify package revisions local.conf, that's really for the developer/user to tweak, and it should not be stored in vcs, doings so just causes pain. That's something that's come up in our side conversations here: local.conf is really for developers to tweak. I will try to take care and not use local.conf for such a thing, and I will not store it in a VCS unless I can think of a really compelling reason to do so. Thanks for the advice there. I use the unified include file in Guacamayo for the packages that we maintain; this is for convenience, as during the development cycle I use AUTOREV for these packages, but for an actual release specify the revisions explicitly and having them all in one place makes this easier to do and not forget anything. See, https://github.com/Guacamayo/meta-guacamayo/tree/master/meta-guacamayo/conf/ for how we got it set up. So, to me it looks like you're using conf/distro/guacamayo.conf to set those revisions. That seems like that might work when there's only a handful of revisions to set. However, we'll likely have at least a hundred packages for which we need to set/manipulate revisions. I would think that would get cumbersome, and in an organization the size of ours (500 or so developers across two sites), there's not really going to be one person or team who knows what should go in that file for a release. Moreover, that still leaves the problem of all those developers needing to know there are at least two places in which their package revisions may be controlled. Is your organization significantly smaller than that or are we doing something wrong? Kind regards, Jerrod ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How do you release distros produced with Yocto? How should I?
On Tue, Oct 02, 2012 at 12:43:27PM -0400, Jerrod Peach wrote: All, After spending a few years working with a several-years old forked and heavily-modified version of BitBake, my company is looking at switching to using Yocto to build embedded Linux for its printers. I've been playing with/writing tools and process around Yocto for a couple of months now, and I'm getting to the point where I can produce integration builds without a problem. Now I'm starting to think about how our release process should work with pure Yocto and I'm running into a conundrum. Before I get into that, though, let me very briefly explain how we release code currently in terms of Yocto as it is today. This is not exactly what we do, but if I had to explain the real process, it would take a while because of all the customization we bolted on top of our forked BitBake. Basically, we have a branch in a repository containing the equivalent of local.conf, and we put fixed revisions of every package for that release into the local.conf file within that branch. As patches for a release come in, the local.conf file is updated to point to the new patches. I was thinking about doing something very close to that in actual Yocto, except I'd store only the revisions/branches that were different from what the bb file prescribed in local.conf. I ran that idea by a couple of colleagues separately and they both immediately pointed out a concern: they didn't want to have two different places that could manage the revision of the package, i.e. local.conf and the package bb file. They don't like how that works in the system we have today. Instead, they wanted to branch all the metadata and have people update individual bb files with different revisions as necessary. That leaves only one place to manage the revision: the package bb file. Doing all that branching concerns me (it seems heavier-weight than it needs to be, at the very least), but I can't say specifically why branching the bb files is harmful. If you guys can think of a reason why, let me know. If you think it's reasonable, let me know that too. I think that branching (or tagging) whole metadata is best option, use AUTOREV from some .inc file (included in local.conf) for development and then just before release update in recipe SRCREVs with small script from bitbake persistent cache (tmp-eglibc/cache/bb_persist_data.sqlite3). This way you will get correct SRCREVs in branched metadata and won't need so many recipe updates during development to move SRCREV too often. Cheers, I'm also starting to think there might be a better way to handle this with Yocto's concept of distros (perhaps have a distro for printer X, and a different one for printer Y, each pointing at versions of code that are good for the respective printer), but my research so far hasn't given me enough information on distros to know if this is a reasonable approach. (I've poked through some of the documentation and the mailing list archives.) So, what do you all do for releasing code? Does anyone have a situation similar to mine? (I can't imagine I'm unique, but maybe I'm more special than I thought.) Even if you don't have a situation like mine, what would you suggest I do for releasing code for our printers? Kind regards, Jerrod ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ 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
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. Cheers, 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...@gmail.com signature.asc Description: Digital signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Can't fetch git SRC_URI via HTTP
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. -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...@gmail.com ___ 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] Can't fetch git SRC_URI via HTTP
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...@gmail.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ 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:
Re: [yocto] Can't fetch git SRC_URI via HTTP
On 10/02/2012 02:17 PM, 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: I just would like to comment that this is one of the best requests for help I've seen on this mailing list. Kudos for including all the relevant information! Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Can't fetch git SRC_URI via HTTP
On Tue, Oct 02, 2012 at 03:09:19PM -0700, Scott Garman wrote: On 10/02/2012 02:17 PM, 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: I just would like to comment that this is one of the best requests for help I've seen on this mailing list. Kudos for including all the relevant information! Well except that important part, that he has changed git:// to http:// in SRC_URI.. It would be even easier to help him if he says only: I've changed git:// to http:// in SRC_URI and now bitbake cannot fetch it anymore :) Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] meta-cedartrail: add missing dependency on EXA module to X driver
Pulled into meta-intel/master.
Thanks,
Tom
On Tue, 2012-10-02 at 11:11 +0100, Ross Burton wrote:
[YOCTO #3204]
Signed-off-by: Ross Burton ross.bur...@intel.com
---
.../recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.3.bb|3
++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
a/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.3.bb
b/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.3.bb
index afda9dd..cd3407c 100644
--- a/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.3.bb
+++ b/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.3.bb
@@ -14,7 +14,7 @@ LIC_FILES_CHKSUM = \
DEPENDS = rpm-native libva
-PR = r1
+PR = r2
PSB-VIDEO = psb-video-cdv-1.0.3-1.1.i586.rpm
PSB-VIDEO-REV = 1.0.3
@@ -66,6 +66,7 @@ FILES_${PN} += ${libdir}/pvr/cdv/xorg/modules/drivers
FILES_${PN} += ${datadir}/doc/psb-video-cdv-${PSB-VIDEO-REV}/license.txt
FILES_${PN} += ${datadir}/doc/pvr-bin-cdv-${PVR-BIN-REV_LIC}/license.txt
+RDEPENDS_${PN} = xserver-xorg-module-exa
TARGET_CC_ARCH += ${CFLAGS}{LDFLAGS}
INSANE_SKIP_${PN} += ldflags
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, October 02, 2012 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US Canada).
Attendees: David Wolf, Michael, Mark, AlexG, Bjorn, Dave, Paul, Jessica, Ross, Saul, Beth, Kevin, Richard, Bruce, Nitin, LaurentiuP, Cristian, ScottR, Jeff, MihaiL, Denys, Song Agenda: * Opens collection - 5 min (Song) - Congrats to the team on M4 release. * Yocto 1.3 status - 10 min (Song/team) https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status - Status wiki page updated, bug fixing on the right direction, total # of bugs down. - RC3 this week, please get fixes in as soon as possible. - We will be scrutinizing patches more carefully to make sure it's not something invasive that could destabilize the master. - Most of the high bugs have solutions and can be closed within a week. - Medium+ bugs review: . 3143: has a workaround. Laurentiu will send workaround patches. . 3176: there is a solution but hard to implement. May need to move to 1.4 . 3183: did improve with better messaging. May need to push to 1.4. Richard/Dave will decide. . 3186: Bruce/mark will look into this and find someone from Wind River to fix. . 3119/3175: cristian. Work with Paul. Need to get this one fixed . Others are mostly ok and can be turned around in a week or so. * SWAT team rotation: Mihai Liner - Saul * Opens - 10 min * Team sharing - 20 min - Michael: Updated bugzilla last week. Should not affect functionality. Bugzilla reports, fixed the schedule wiki problem. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/1] meta-intel: 'universe' build fix
From: Tom Zanussi tom.zanu...@intel.com This patchset fixes a build problem seen in a meta-intel-gpl build. The following changes since commit 97bf8bacd0e0e1fd67f4dcc5dff4237f7ff1ccbf: meta-cedartrail: add missing dependency on EXA module to X driver (2012-10-02 17:21:26 -0500) are available in the git repository at: git://git.yoctoproject.org/meta-intel-contrib.git tzanussi/make-gst-va-intel-commercial http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-contrib/log/?h=tzanussi/make-gst-va-intel-commercial Tom Zanussi (1): gst-va-intel: incude gst-ffmpeg only if 'commercial' is whitelisted common/recipes-multimedia/gstreamer/gst-va-intel.bb | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- 1.7.11.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/1] gst-va-intel: incude gst-ffmpeg only if 'commercial' is whitelisted
From: Tom Zanussi tom.zanu...@intel.com
World and universe builds break if the newly commercial gst-ffmpeg is
included without a 'commercial' entry in LICENSE_FLAGS_WHITELIST, so
only add gst-ffmpeg if that's the case.
Normally BSPs conditionally include gst-va-intel and thus gst-ffmpeg
is included in the build only if 'commercial' is added to
LICENSE_FLAGS_WHITELIST and therefore this isn't an issue, but world
and universe builds are different.
Signed-off-by: Tom Zanussi tom.zanu...@intel.com
---
common/recipes-multimedia/gstreamer/gst-va-intel.bb | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/common/recipes-multimedia/gstreamer/gst-va-intel.bb
b/common/recipes-multimedia/gstreamer/gst-va-intel.bb
index 516e5f1..ee04839 100644
--- a/common/recipes-multimedia/gstreamer/gst-va-intel.bb
+++ b/common/recipes-multimedia/gstreamer/gst-va-intel.bb
@@ -4,7 +4,7 @@ DEPENDS = gst-meta-base
LIC_FILES_CHKSUM =
file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420
-PR = r1
+PR = r2
def map_gst_vaapi(d):
if base_contains('MACHINE_FEATURES', 'va-impl-mixvideo', 1, 0, d) ==
1:
@@ -31,7 +31,8 @@ RDEPENDS_gst-va-intel = \
RDEPENDS_gst-va-intel-general = \
-gst-ffmpeg \
+${@bb.utils.contains(LICENSE_FLAGS_WHITELIST, \
+commercial, gst-ffmpeg, , d)} \
RDEPENDS_gst-va-intel-video = \
--
1.7.11.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
