Re: Can't fetch git SRC_URI via HTTP
Julian Scheel <julian@...>
Am 02.10.2012 um 23:22 schrieb Martin Jansa <martin.jansa@...>:
On Tue, Oct 02, 2012 at 05:17:23PM -0400, Evade Flow wrote:I ran into the same issue a few days ago. It seems yocto only supports git fetchI'm trying to build core-image-sato for my Pandaboard ES, following theThis url seems wrong, it should start with git:// if you want to clone 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 \From what I can tell, though, bitbake isn't handling this SRC_URI
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Re: Can't fetch git SRC_URI via HTTP
Martin Jansa
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 theThis 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 \From what I can tell, though, bitbake isn't handling this SRC_URI Martin 'JaMa' Jansa jabber: Martin.Jansa@...
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Can't fetch git SRC_URI via HTTP
Evade Flow <evadeflow@...>
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:I have these lines in my .gitconfig: [http]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 \From what I can tell, though, bitbake isn't handling this SRC_URI correctly, and I get: ERROR: Command Error: exit status: 1 Output: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"And this is my bblayers.conf: # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Yocto Bug Trend
Serban, Laurentiu <laurentiu.serban@...>
Hello guys,
The Yocto Bug Trend page was updated for ww39 https://wiki.yoctoproject.org/wiki/Yocto_Bug_Trend. The data is also available in the attached excel file.
Best regards, Laurentiu
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Re: How do you release distros produced with Yocto? How should I?
Martin Jansa
On Tue, Oct 02, 2012 at 12:43:27PM -0400, Jerrod Peach wrote:
All,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 _______________________________________________ -- Martin 'JaMa' Jansa jabber: Martin.Jansa@...
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Re: How do you release distros produced with Yocto? How should I?
Jerrod Peach <peachj@...>
Tomas,
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 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.
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
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[PATCH 1/1] [meta-intel] meta-crystalforest: Create a custom build Image recipe.
kishore.k.bodke@...
From: Kishore Bodke <kishore.k.bodke@...>
To build with the corpus files recipes, create a customized recipe to install them into the Image. Signed-off-by: Kishore Bodke <kishore.k.bodke@...> --- .../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 0000000..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.bodke@... +# + +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 0000000..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.bodke@... +# + +require recipes-sato/images/core-image-sato.bb + +IMAGE_INSTALL += " \ + calgary-corpus \ + canterbury-corpus \ + silesia-corpus \ + " + +LICENSE = "MIT" + +PR = "r0" -- 1.7.9.5
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[PATCH 0/1][meta-intel] Add a custom Image recipe
kishore.k.bodke@...
From: Kishore Bodke <kishore.k.bodke@...>
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
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Re: How do you release distros produced with Yocto? How should I?
Tomas Frydrych <tf+lists.yocto@...>
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 withSounds 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
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
How do you release distros produced with Yocto? How should I?
Jerrod Peach <peachj@...>
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'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
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Tftp Server Problem P1021rdb
Maxime Moge <Maxime.Moge@...>
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
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Full pass test results for 1.3 RC2
Serban, Laurentiu <laurentiu.serban@...>
Hello,
Here are the results for 1.3 M4 RC3 full pass testing. The commit id is: 718eb85806e080d0b165344b272e531ef19421eb. The following issue are encountered: - For the BSPs: o For e-menlow the X server is not starting (3091) o For FRI2 – connman does not provide a 3g configuration utility (2415), system cannot enter S3 standby mode (2037), there is dmesg PowerButton error (2989) and the system cannot enter S3 standby mode (2037), Windows switching failure (2646), [FRI2]No WiFi section available in connman (3202) o For qemu x86_64 images – the zypper refresh fails (2694), o For all the boards there is common issue with the Sudoku-savant application (2878) and with the warnings at boot time (2399) - For core build system: o There are still errors with the do_rootfs fails for lib64-core-image-sato-sdk (2918), there is a small issue with the sstate-cache-management.sh (3116) and there is a problem related to meta-intel BSP creation using yocto-bsp. - For ADT o There are issues with the lttng (3203) and meta-toolchain-support (3100). o There is an issue using the standalone toolchain for ARM and x86 (3201) - For HOB: o Choosing another toolchain host than x86_64 produces an hob-toolchain error (3199) o Improve bblayers-hob.conf (3007)
The build for core-image-sato with pre-fetched sources takes 84 minutes
Best regards, Laurentiu Serban
Open Source Technology Center System Software Division Romania Desk: +40 31 8604742 iNET: 88451042
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Re: Cannot do atom-pc build with meta-cedartrail
Tom Zanussi <tom.zanussi@...>
On Tue, 2012-10-02 at 18:00 +0300, Mihai Lindner wrote:
On 2012-09-29 23:50, Ross Burton wrote:It shouldn't though, since the application of the meta-tlk SRC_URIOn Thursday, 27 September 2012 at 18:07, Tom Zanussi wrote:Unfortunately this change breaks SRC_URI appends, discarded or overwritten; e.g. adding meta-tlk brings no change to SRC_URI.Yeah, looks like the other SRC_URIs do that, but it's missing from thatThanks Tom, I've been frequently flipping between atom-pc and cedartrail and this was getting annoying. 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/meta 5 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
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Re: Cannot do atom-pc build with meta-cedartrail
Mihai Lindner <mihaix.lindner@...>
On 2012-09-29 23:50, Ross Burton wrote:
On Thursday, 27 September 2012 at 18:07, Tom Zanussi wrote:Unfortunately this change breaks SRC_URI appends, discarded or overwritten; e.g. adding meta-tlk brings no change to SRC_URI.Yeah, looks like the other SRC_URIs do that, but it's missing from thatThanks Tom, I've been frequently flipping between atom-pc and cedartrail and this was getting annoying. -- Mihai Lindner
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Re: Howto add TIPC-support into kernel?
Bruce Ashfield <bruce.ashfield@...>
On 12-10-02 05:23 AM, Jonas Jonsson L wrote:
Hi!Are you primarily concerned with getting the kernel options enabled and then the built modules installed onto your target ? (I ask because TIPC userspace can come into play .. depending on your usecase). If so, you'd want to add a linux-yocto_3.4.bbappend (assuming you are using the 3.4 kernel) to your layer, and put your options into a .cfg fragment that you append to the SRC_URI (just like any patch or other file). Those options will be added to the config on your next build and installed. In that same layer, you can add kernel-modules to IMAGE_INSTALL and you'll get the build and install whenever the layer is active. There are other ways to do this as well, but what I have above is what I typically do in a distro or BSP layer. Cheers, Bruce Thanks!
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Re: [PATCH 00/62] denzil pull request 2
Richard Purdie
On Mon, 2012-09-24 at 17:29 -0700, Scott Garman wrote:
The following changes since commit 65ffa7395055f7e012cb973f63f92380828eed0d:These got merged to the denzil branch, thanks. Richard
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[PATCH] meta-cedartrail: add missing dependency on EXA module to X driver
Ross Burton <ross.burton@...>
[YOCTO #3204]
Signed-off-by: Ross Burton <ross.burton@...> --- .../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" -- 1.7.10
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Howto add TIPC-support into kernel?
Jonas Jonsson L <jonas.l.jonsson@...>
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
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Agenda: Yocto Project Technical Team Meeting - Tuesday, October 02, 2012 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).
Liu, Song <song.liu@...>
Agenda:
* Opens collection - 5 min (Song) * Yocto 1.3 status - 10 min (Song/team) https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status * SWAT team rotation: Mihai Liner - > 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.7777 US Toll Free number: 1.877.561.6828 BlackBerry users, click this link to join your conference as a participant: 1.972.995.7777x76994298# 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-9957777 or 8784277 Beijing Out of Office dial 5878 4277 China (Shanghai): From office dial 8-9957777 or 3073322 Shanghai Out of Office dial 2307 3322 China (Shenzen): From office dial 8-9957777 or 6007877 Shenzen Out of Office dial 2600 7877 China (Other Cities): From IP phone dial 8-9957777 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 89957777 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 7777 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 7777 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
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Re: Runtime update of yocto-images
Marc Ferland <ferlandm@...>
Julian Scheel <julian@...> writes:
Hi,This is the approach that I've taken. Works fairly well. You will need to: - Create your own init script (look in: meta/recipes-core/initrdscripts/files as a starting point) - Patch your kernel with AUFS/unionfs/overlayfs if you want something that is not 100% volatile. - Create an "install/update" script that actually takes care of updating your squashfs rootfs from the initramfs. Marc
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|