Date   

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'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:passwd@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@...
https://lists.yoctoproject.org/listinfo/yocto
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@...
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


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 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:passwd@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@...
https://lists.yoctoproject.org/listinfo/yocto
--
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:
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:passwd@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 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,

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@...
https://lists.yoctoproject.org/listinfo/yocto

--
Martin 'JaMa' Jansa jabber: Martin.Jansa@...


Re: How do you release distros produced with Yocto? How should I?

Jerrod Peach <peachj@...>
 

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
 


[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 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


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

 

 

  

Critical bugs, more than 50% test cases are blocked

 

Only Normal, Minor or Enhancement bugs, or less than 10% test cases failed

 

Normal, Major and Critical bugs, and more than 10% test cases failed

 

Test Result Summary

Component

Target

Status

Comments

p1022ds

GOOD

Sudoku-savant issue (2878)

BSP

Beagleboard

GOOD

Sudoku-savant issue (2878)

Routerstationpro

GOOD

Sudoku-savant issue (2878)

Mpc8315e-rdb

GOOD

Sudoku-savant issue (2878)

eMenlow-sato-sdk

BUGGY

Sudoku-savant issue (2878)

X does not start on E-Menlow bsp (3091)

Blacksand-sato-sdk

GOOD

Sudoku-savant issue (2878)

Sugarbay sato-sdk

GOOD

Sudoku-savant issue (2878)

Crownbay-emgd-sato-sdk

GOOD

Sudoku-savant issue (2878)

FRI2-sato

BUGGY

Live boot from USB fails (2399),

standby issue (2037),

Sudoku-savant build issue (2878),

system dmesg log check issue (2989),

3G issues with connman (2415)

[FRI2]No WiFi section available in connman (3202)

HuronRiver-sato

GOOD

Sudoku-savant issue (2878)

Jasperforest-lsb

GOOD

Sudoku-savant issue (2878), zypper is not installed in core-image-lsb-sdk (3098)

QEMU

 

 

 

Qemuarm

GOOD

Everything runs well

Qemuppc

GOOD

Everything runs well

Qemumips

GOOD

Everything runs well

qemux86

GOOD

Everything runs well

qemux86-64

BUGGY

Zypper issue (2694)

Core build system

 

BUGGY

incremental RPM generation (3047),

lib64-core-image-sato-sdk fails due to do_rootfs issue (2918)

[multilib]do_rootfs failed for lib32-connman-gnome with ipk (2590)

sstate-cache-management.sh prints some error message when running (3116)

HOB

 

GOOD

[HOB]toolchain arch in settings is not saved (3199)

Improve bblayers-hob.conf (3007)

ADT

 

BUGGY

autoreconf run failed on x86-64 gmae-toolchain (3100)

cannot build Hello World Ansi C project using standalone Toolchain for ARM and X86 (3201)

kernel trace type not available in the lttng project (3023)

Stress Testing

GOOD

Both Crashme and Helltest on Jasperforest could pass 24 hours stress testing

Distribution Support

GOOD

Everything runs well for Ubuntu 12.04, Ubuntu 12.10 – nightly, OpenSuse 12.1, OpenSuse 12.2 RC2, Fedora 17, CentOs 6.3, Fedora 16

Power and Performance

GOOD

one qemux86 sato build on a Core i7 machine costs 84 minutes with the packages previously fetched.

Compliance

GOOD

Tests on Huron River and BlackSand passed

Build Appliance

GOOD

Everything runs well on VMWare Player (on Ubuntu). The relevant tests were performed also for qemu-kvm on Fedora 17 libvirt and

VMWare Workstation.(Ubuntu)

 

 

 

 

 

 

 

Detailed Test Result for each component

Target

Total TCs

Not Run

Passed

Failed

Not testable (Blocked)

Beagleboard Sato-SDK

42

0

37

5(2878, 3186, 3159)

0

Routerstationpro Sato-SDK

35

0

34

1(2878)

0

p1022ds-sato-sdk

37

0

36

1(2878)

0

Mpc8315e-rdb Sato-SDK

37

0

36

1(2878)

0

eMenlow Sato-sdk

67

0

35

32(bug 2878,3091)

0

n450 Sato-sdk

67

0

66

1 (bug 2878)

0

Crownbay-Sato-sdk

65

0

62

1(2878)

2(hardware issues to be solved)

FRI2 Sato-sdk

86

0

67

19(2646,2867)

0

HuronRiver Sato-sdk

68

0

67

1(2878)

0

Sugarbay sato-sdk

68

0

67

1(2878)

0

Jasperforest lsb-sdk

34

0

26

8(2878,3098)

0

Qemuarm Sato

31

0

31

0

0

Qemuarm Sato-SDK

36

0

36

0

0

Qemumips Sato

31

0

31

0

0

Qemumips Sato-SDK

36

0

36

0

0

Qemuppc Sato

31

0

31

0

0

Qemuppc Sato-SDK

36

0

36

0

0

Qemux86-64 Sato

30

0

27

3 (bug 2694)

0

Qemux86-64 Sato-SDK

36

0

32

4 (bug 2694)

0

Qemux86 Sato

30

0

30

0

0

Qemux86 Sato-SDK

36

0

36

0

0

Core build system

64

0

59

5 (2918, 3116,3178)

0

HOB

39

0

37

2(3199,3007 )

0

ADT

53

0

30

23(3201, 3203, 3100)

0

Build Appliance

14

0

14

0

0

Total

1109

0

999

108

2

 

Component

Bug Number

Target Milestone

System & Core OS

System Usage

Bug 2878 pkgconfig is missing from sato-sdk image - installing and then trying to removing it leads to rpm crashes/assertions

Bug 3091 X does not start on E-Menlow bsp

Bug 2037 [fri2] system cannot enter S3 standby mode

Bug 2399 gdk-pixbuf: hundreds of warnings on boot

Bug 2415 connman doesn't provide a 3g configuration utility

Bug 2989 [FRI2] dmesg PowerButton error

Bug 2694 [QEMU-X86_64]zypper refresh fail

Bug 2646 Windows switching failure

Bug 3202 No WiFi section available in connman

Core build system

Bug  3116 sstate-cache-management.sh prints some error message when running

Bug 3178 building a power pc image with a layer created using yocto-bsp fails due to cfg/vfat not available

Bug 2918  lib64-core-image-sato-sdk fails due to do_rootfs issue

ADT

Bug 3100 autoreconf run failed on x86-64 gmae-toolchain

Bug 3201 cannot build Hello World Ansi C project using standalone Toolchain for ARM and X86

Bug 3203 kernel trace type not available in the lttng project

HOB

Bug 3199 Choosing another toolchain host than x86_64 produces an hob-toolchain error

Bug 3007 Improve bblayers-hob.conf

 

 

 

 

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:
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/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:
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


Re: Howto add TIPC-support into kernel?

Bruce Ashfield <bruce.ashfield@...>
 

On 12-10-02 05:23 AM, Jonas Jonsson L wrote:
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.
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!
Best regards,
Jonas Jonsson


_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


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:

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


[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,

I wonder how everyone deals with runtime updates of yocto based
systems? Are you using the package management for this? Actually I'd
prefer a one-file update, which would replace the whole rootfs. I
think having a squashfs image containing the rootfs and place it on
some ext-partition would be nice. One would just need an initramfs,
that could mount the squashfs file as root.

Is anyone following an approach like this?
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