Date   

Re: Multiple Repository support

Esben Haabendal <eha@...>
 

On Wed, 2010-12-22 at 11:09 -0500, Cliff Brake wrote:
Hello,

I've started collecting ideas from various emails on multiple
repository support.

http://wiki.openembedded.org/index.php/MultipleRepositoryMethods

Please feel free to update the above page.

In my mind, this is a key problem we need to solve, not just for
Yocto/OE, but also for anyone doing product development.

I've personally been using git submodules for most projects, and repo
for Android based projects.

Appreciate any ideas, experiences, or insights into how we solve this problem.
We are using git submodules for just this task in OE-lite.
It works pretty well, but I fear that this will not be the case if a
push model is used for the top repository.

We have partly wrapped the git submodule configuration into a bitbake
parsed configuration file, looking something like:

# OE-lite/core metadata
OE_MODULES += "core"
OE_MODULE_PATH_core = "meta/core"
OE_MODULE_URL_core =
"git://git.doredevelopment.dk/oe-lite/core.git"
OE_MODULE_PUSHURL_core =
"ssh://dev.doredevelopment.dk/srv/public/git/oe-lite/core.git"
OE_MODULE_BRANCH_core = "master"
OE_MODULE_REMOTES_core += "gitorious"
OE_MODULE_REMOTE_core_gitorious = "git@...:oe-lite/core.git"

So developers get a more complete and consistent submodule setup.

We considered repo, but the KISS principle ruled in favor of git
submodules. I believe the learning curve is steep enough for any
newcomers to OE, so having to figure out how to master something like
repo also does not seem so attractive.

/Esben

/Esben


[PATCH 1/1] linux-yocto: add dropped qemuppc configuration

Bruce Ashfield <bruce.ashfield@...>
 

The _ to - mass change mangled a config file name, which was
dropped from the update. This adds the fixed file back to the
meta branch of the kernel.

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
.../conf/distro/include/poky-default-revisions.inc | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/conf/distro/include/poky-default-revisions.inc b/meta/conf/distro/include/poky-default-revisions.inc
index 9605336..03e788b 100644
--- a/meta/conf/distro/include/poky-default-revisions.inc
+++ b/meta/conf/distro/include/poky-default-revisions.inc
@@ -106,7 +106,7 @@ SRCREV_machine_pn-linux-yocto_atom-pc = "f6454fa1af4340832f8943f0b3d8e9f2de11b1b
SRCREV_machine_pn-linux-yocto_routerstationpro = "f0d79e2ae0cbb3924c57655b8c7d6a1276c9fc05"
SRCREV_machine_pn-linux-yocto_mpc8315e-rdb = "a0243e84c1cca7fb625ae4bd76274882ccbe4333"
SRCREV_machine_pn-linux-yocto_beagleboard = "f6454fa1af4340832f8943f0b3d8e9f2de11b1b1"
-SRCREV_meta_pn-linux-yocto ?= "7ca94548e68a72e57715d65d6d8f723582aafa59"
+SRCREV_meta_pn-linux-yocto ?= "5955ebea1f0d2fbd67a66ed138ce2b3363adf72a"
SRCREV_pn-linux-libc-headers-yocto ??= "f6454fa1af4340832f8943f0b3d8e9f2de11b1b1"
SRCREV_pn-matchbox-config-gtk ??= "2081"
SRCREV_pn-matchbox-desktop-sato ??= "76"
--
1.7.0.4


[PATCH 0/1] linux-yocto: add dropped qemuppc configuration

Bruce Ashfield <bruce.ashfield@...>
 

The _ to - mass change mangled a config file name, which was
dropped from the update. This adds the fixed file back to the
meta branch of the kernel.

Pull URL: git://git.pokylinux.org/poky-contrib.git
Branch: zedd/qemuppc-fix
Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/qemuppc-fix

Thanks,
Bruce Ashfield <bruce.ashfield@...>
---


Bruce Ashfield (1):
linux-yocto: add dropped qemuppc configuration

.../conf/distro/include/poky-default-revisions.inc | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)


Master stability and the autobuilder.

Elizabeth Flanagan <elizabeth.flanagan@...>
 

All,

In preparation for the M3 milestone, I've been taking notes on what our
build and release process is and where the pain points are over the
course of the M2 milestone. A few things I've noted that are concerning:

1. We have a really long build cycle. It takes a good 40 hours before
contamination of master is recognized and a further 40 hours *at the
very minimum* before it can be verified as corrected.

2. We are very resource constrained. Because the build loop is so long,
our two build slaves are essentially in use 24/7. This will be
alleviated soon with a new build slave, but not until after the new year.

3. There was an issue in M2 (which I'm not totally filled in on yet, I'm
going to be pinging people for details) which caused some kernel issues
around the M2 branch for ppc and arm. I haven't seen (and I've been
swamped with email recently, so I may have missed it) any resolution on
this in master.

4. People are relying on the autobuilder to do their builds or to verify
their code.

My main goal in M3 and on, is the stability of master. If we were less
resource constrained, I could allow the autobuilder to be a global
community resource where people could just queue up their various
builds. That, unfortunately, is not the case for now. What this means is
that I have to ask people for a few things.

1. I'll be cleaning up the poky autobuilder config within the git repo
and making it very developer specific so that you should be able to run
a script and have the autobuilder set up to run incremental and fulls
(and an optional swabber target) on your own machine and have it work
right out of the box. Once my pull for the new autobuilder comes
through, please, set up your own local autobuilder instance. This should
be by the EOD today. I'll be somewhat available through the holidays to
assist people with local machine setups, but it should be fairly
straightforward.

2. Please, make certain that your code builds on your local buildbot
before submitting a pull request. As the project grows, maintaining the
stability of master will become more and more important and the limited
resources of our maintainers and our infrastructure will become more and
more stretched.

3. I've dropped this recently, due to limited time, but I'm going to
start sending out more and more broken build emails. Please, do not
ignore these. Act on them. If you're think you may be responsible for
something that is broken, let people know that you recognize the
breakage and what you're planning on doing to fix it.

4. Until we know that master is stable (right now I know of 3 or 4
issues, email forthcoming), the autobuilder will be tasked with a very
limited number of buildsets. I'll be generating a milestone type build
off of master to get some quicker response (20 hours verses 38), and
incremental versions of milestone and sanity testing. We will still be
running nightly (although you can't see it on the autobuilder right now)
and distro-testing but until master is stable, those have got to be the
priorities on the autobuilder.

-b


website

Jeff Osier-Mixon <jefro@...>
 

Hi all - Dave posted a request for website feedback on the blog. 

One idea that has worked well in other communities (including meld.org) is video walkthroughs of basic things, like setting up the environment, doing a first build, etc.  Android does this - they don't have to be exciting or long, in fact the shorter the better, but it really helps for them to exist.  There are several software packages that make it a breeze.

keep up the good work,

Jeff


Re: Ideas for yoctoproject.org improvements

David Stewart
 

From: Christophe Aeschlimann [mailto:c.aeschlimann@...]
Sent: Wednesday, December 22, 2010 1:32 AM

I've just started looking at Yocto, but I have been following
OpenEmbedded progress for two years now. So I don't have any comment yet
on the yoctoproject website content but I noticed that :

https://www.yoctoproject.org/

Leads to a broken, default, mailman page. Maybe this can be fixed ?
Great catch - thanks!


Re: Multiple Repository support

Bruce Ashfield <bruce.ashfield@...>
 

On 10-12-22 11:09 AM, Cliff Brake wrote:
Hello,

I've started collecting ideas from various emails on multiple
repository support.

http://wiki.openembedded.org/index.php/MultipleRepositoryMethods

Please feel free to update the above page.

In my mind, this is a key problem we need to solve, not just for
Yocto/OE, but also for anyone doing product development.

I've personally been using git submodules for most projects, and repo
for Android based projects.

Appreciate any ideas, experiences, or insights into how we solve this problem.
We've used (and walked away) from git submodules in the
past for some really large projects. Our experiences closely
match "the bad" on the wiki link you sent. I've met very
few people who can effectively manage active development
in a git submodule based environment. My blunt opinion is
that if I never see another one in my life, I'd probably
be happy. I haven't looked at a submodule in about a year,
so maybe they have been fixed for the better .. but I'm
skeptical.

The solution to the submodule chaos that was used
sucessfully was to create something we called
'subgits'. They use git, a wrapper script and standard
git configs. A subgit points to a remote repo, specifies
where it should be cloned, and has a place for special
properties. You can recursively pull from a top level
and have all subgits updated in a uniform fashion. The
model can be extended for multi repository development
as well. The big win here is that you can independently
update repos, use normal git workflows, or wrap it as
you want. Nothing is forced.

Note: all the functionality of submodules isn't present
here (global tracking, bisect, etc), but that was functionality
that wasn't really crucial.

Just some comments and opinions to throw into the
discussion.

Cheers,

Bruce




Thanks,
Cliff


Multiple Repository support

Cliff Brake <cliff.brake@...>
 

Hello,

I've started collecting ideas from various emails on multiple
repository support.

http://wiki.openembedded.org/index.php/MultipleRepositoryMethods

Please feel free to update the above page.

In my mind, this is a key problem we need to solve, not just for
Yocto/OE, but also for anyone doing product development.

I've personally been using git submodules for most projects, and repo
for Android based projects.

Appreciate any ideas, experiences, or insights into how we solve this problem.

Thanks,
Cliff

--
=================
http://bec-systems.com


Sanity Test Report for Yocto M2 20101218 Build

Xu, Jiajun <jiajun.xu@...>
 

Hi all,

       This is the Sanity Test Report for M2 20101218 build. QA finished sanity+weekly test cases. There are 6 new bugs found in this testing. mpc8315e-rdb testing is BLOCKED because of no image built out. Toolchain is found a link issue. 2 old bugs are verified fixed. The basic function of all supported targets can work, including network, X window and basic system usage. QA will continue fullpass testing with this build if there is no other concern.

 

Test Summary

---------------------------------------

Target

Total TCs

Not Run

Passed

Failed

Not testable (Blocked)

Poky build system

2

0

0

2 (bug 598, bug 599)

0

Netbook SDK

74

49

25

0

 

eMenlow Minimal

27

12

15

0

0

Blacksand SDK

65

40

24

1 (bug 607)

0

Routerstationpro SDK

28

12

16

0

0

BeagleBoard Sato

11

7

4

0

0

BeagleBoard SDK

16

9

7

0

0

Mpc8315e-rdb SDK

28

28

0

0

28 (bug 610)

Qemux86-64 Sato

19

6

13

0

0

Qemux86-64 SDK

26

8

18

0

0

Qemux86 Sato

19

6

13

0

0

Qemux86 SDK

26

8

18

0

0

Qemumips Sato

19

7

12

0

0

Qemumips SDK

26

9

15

2 (bug 604)

0

Qemuppc Sato

19

8

8

3 (bug 443)

0

Qemuppc SDK

26

10

11

5 (bug 443, bug 604)

0

Qemuarm Sato

19

6

13

0

0

Qemuarm SDK

26

8

16

2 (bug 604)

0

Total

476

233

228

15

28

* You can check the detailed test result in attachment for each target.

** The failed/blocked case number is listed with failed cases’ bug number.

*** The “Not Run” cases contains test cases, blocked by some critical bug, or the “Fullpass” test cases, which are not supposed to execute sanity test cycle.

 

Images

---------------------------------------

http://autobuilder.pokylinux.org/milestone/20101218-1/

 

Issue Summary

---------------------------------------

New Bugs:

1.     no rootfs and dtb file in qemumpc8315e-rdb milestone build

http://bugzilla.pokylinux.org/show_bug.cgi?id=610

2.     [RouterStation] The timestamp of new file created under /home/root doesn't correct after adjusting the time

http://bugzilla.pokylinux.org/show_bug.cgi?id=609

3.     [rpm/zypper] remove_packaging_data_files makes rpm/zypper install/remove not work in minimal image

http://bugzilla.pokylinux.org/show_bug.cgi?id=608

4.     [Blacksand] Some error information prompted when run dmesg command

http://bugzilla.pokylinux.org/show_bug.cgi?id=607

5.     [toolchain]Build c program failed with arm toolchain

http://bugzilla.pokylinux.org/show_bug.cgi?id=604

6.     [Netbook]Connection preferences did not enable wireless networks

http://bugzilla.pokylinux.org/show_bug.cgi?id=603

 

Old Open Bugs:

1.     [zypper] uname -m and repo arch difference

http://bugzilla.pokylinux.org/show_bug.cgi?id=489

2.     [zypper] installation failure on arm

http://bugzilla.pokylinux.org/show_bug.cgi?id=490

3.     [zypper] package removal failure

http://bugzilla.pokylinux.org/show_bug.cgi?id=491

4.     zypper encounter segfault when startup with qemuppc

http://bugzilla.pokylinux.org/show_bug.cgi?id=443

5.     qemumips shutdown cause host console warning

http://bugzilla.pokylinux.org/show_bug.cgi?id=322

6.     [poky] kernel interactive build does not work via ssh

http://bugzilla.pokylinux.org/show_bug.cgi?id=598

7.     [poky] qemu running with KVM needs root permission

http://bugzilla.pokylinux.org/show_bug.cgi?id=599

 

 

Verified Fixed Bugs:

1.     [Netbook] Installer no response after loading from live image

http://bugzilla.pokylinux.org/show_bug.cgi?id=566

2.     PPC is failing to build

http://bugzilla.pokylinux.org/show_bug.cgi?id=585

 

 

Best Regards,

Jiajun


Re: Ideas for yoctoproject.org improvements

Christophe Aeschlimann <c.aeschlimann@...>
 

Hi,

On 21.12.2010 20:01, Stewart, David C wrote:
Hello Yocto Project –


I was asked yesterday what kinds of things we might do to improve the
project website, http://www.yoctoproject.org – I have a few opinions on
the subject, but I thought I would put the question to you.



Where can we do better? What kinds of frustrations did you have with the
site when you first got involved with the project? How could it improve
the experience of people becoming familiar with the project?
I've just started looking at Yocto, but I have been following
OpenEmbedded progress for two years now. So I don't have any comment yet
on the yoctoproject website content but I noticed that :

https://www.yoctoproject.org/

Leads to a broken, default, mailman page. Maybe this can be fixed ?

If you want to use this email thread, that would be great. Or if you
prefer to file issues in bugzilla.yoctoproject.org, that would be great too.

Thanks!

Dave
Best Regards,

--
Christophe Aeschlimann

Embedded Software Engineer

ACN Advanced Communications Networks S.A.

Rue du Puits-Godet 8a
2000 Neuchâtel, Switzerland

Tél. +41 32 724 74 31

c.aeschlimann@...


Re: Questions about the name of qemu bin file for different archs

Ke, Liping <liping.ke@...>
 

Hi, Bruce

Lost this mail and finally found it.

Thanks for your detailed explanation.


And so, for easily fetching those qemu images, we need to make sure that
these symbol-link must be created according to the defined naming convention in the build-result-repository.
I will check this problem firstly.

Thanks & Regards,
criping


On 10-12-14 02:40 AM, Ke, Liping wrote:
Hi, Jessica

I found qemu bin file name convention is different for different
archs, for example, for x86, it is bzImage-qemuXXX.
For arm, it is zImage-qemuXXX. My question is why it is bzXXX or zXXX,
is there any reason of such naming convention?

The leading part of the image name is dependent
on the type of kernel we are booting.

]> grep KERNEL_IMAGETYPE qemu*
qemuarm.conf:KERNEL_IMAGETYPE = "zImage"
qemumips.conf:KERNEL_IMAGETYPE = "vmlinux"
qemumips-variant.conf:KERNEL_IMAGETYPE = "vmlinux"
qemuppc.conf:KERNEL_IMAGETYPE = "zImage"
qemux86-64.conf:KERNEL_IMAGETYPE = "bzImage"
qemux86.conf:KERNEL_IMAGETYPE = "bzImage"

And those are your differences in the name.

As for why the symlinks may not be created at times, I'm
not sure.


Or I must did name translate for each kind of arch qemu bin file?
Should be something you can script by checking the
KERNEL_IMAGETYPE.

Cheers,

Bruce



Thanks& Regards,
criping
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


[PATCH 3/3] linux-yocto: update to 2.6.37-rc6

Bruce Ashfield <bruce.ashfield@...>
 

Fixes [BUGID #596]

Updating the SRCREVs of the target branches in the linux-yocto
development kernel to point to 2.6.37-rc6 content.

At this point branches have been switched from _ to - and we
are able to remove the old branch names.

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
.../conf/distro/include/poky-default-revisions.inc | 26 ++++++++++----------
1 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/meta/conf/distro/include/poky-default-revisions.inc b/meta/conf/distro/include/poky-default-revisions.inc
index beffe9a..9605336 100644
--- a/meta/conf/distro/include/poky-default-revisions.inc
+++ b/meta/conf/distro/include/poky-default-revisions.inc
@@ -57,7 +57,7 @@ SRCREV_pn-gypsy ??= "147"
SRCREV_pn-inputproto ??= "7203036522ba9d4b224d282d6afc2d0b947711ee"
SRCREV_pn-inputproto-native ??= "7203036522ba9d4b224d282d6afc2d0b947711ee"
SRCREV_pn-inputproto-nativesdk ??= "7203036522ba9d4b224d282d6afc2d0b947711ee"
-SRCREV_pn-kern-tools-native ??= "796d7fef92b2eed449c17c14441587ff0c465368"
+SRCREV_pn-kern-tools-native ??= "72683bf61fdb83a1c0b4110763f803ff3e39f8ca"
SRCREV_pn-libdrm ??= "3f3c5be6f908272199ccf53f108b1124bfe0a00e"
SRCREV_pn-libfakekey ??= "2031"
SRCREV_pn-libgdbus ??= "aeab6e3c0185b271ca343b439470491b99cc587f"
@@ -96,18 +96,18 @@ SRCREV_machine_pn-linux-yocto-stable_mpc8315e-rdb ?= "986e6eb66c26007cee7916d5d1
SRCREV_machine_pn-linux-yocto-stable_beagleboard ?= "0431115c9d720fee5bb105f6a7411efb4f851d26"
SRCREV_meta_pn-linux-yocto-stable ?= "50ccd2b3213b6a1bacb3f898c035119802dac420"
# development SRCREVs
-SRCREV_machine_pn-linux-yocto_qemuarm = "87e00a2d47ba80b4ad1f9170cb3f6cf81f21d739"
-SRCREV_machine_pn-linux-yocto_qemumips = "7231e473dd981a28e3cea9f677ed60583e731550"
-SRCREV_machine_pn-linux-yocto_qemuppc = "e2b529d7d74a9b21e1d1715f0c4062a4fd92a3ed"
-SRCREV_machine_pn-linux-yocto_qemux86 = "87aacc373557f8849dde8618fbe1f7f8f2af6038"
-SRCREV_machine_pn-linux-yocto_qemux86-64 = "87aacc373557f8849dde8618fbe1f7f8f2af6038"
-SRCREV_machine_pn-linux-yocto_emenlow = "87aacc373557f8849dde8618fbe1f7f8f2af6038"
-SRCREV_machine_pn-linux-yocto_atom-pc = "87aacc373557f8849dde8618fbe1f7f8f2af6038"
-SRCREV_machine_pn-linux-yocto_routerstationpro = "773d3a1c8eba563ffcdbf61057ef6e39cee0c88b"
-SRCREV_machine_pn-linux-yocto_mpc8315e-rdb = "5ff609967ffe87c49d534d7861a7e0b150517726"
-SRCREV_machine_pn-linux-yocto_beagleboard = "87aacc373557f8849dde8618fbe1f7f8f2af6038"
-SRCREV_meta_pn-linux-yocto ?= "ee0a10ab687b29c4d22d47e5b28bc8b3ebb7a8d9"
-SRCREV_pn-linux-libc-headers-yocto ??= "09a39c638dd65dc27c549c119abe1af2631b2ae0"
+SRCREV_machine_pn-linux-yocto_qemuarm = "eeca27d6fb4c7cc8b0ec8e421a51115513740bb9"
+SRCREV_machine_pn-linux-yocto_qemumips = "ed31b5de9b82b9c7e80e93f42822501d0080bcd6"
+SRCREV_machine_pn-linux-yocto_qemuppc = "c01bc9165ab3192368dc2030a98fb75a7f8dc008"
+SRCREV_machine_pn-linux-yocto_qemux86 = "f6454fa1af4340832f8943f0b3d8e9f2de11b1b1"
+SRCREV_machine_pn-linux-yocto_qemux86-64 = "f6454fa1af4340832f8943f0b3d8e9f2de11b1b1"
+SRCREV_machine_pn-linux-yocto_emenlow = "f6454fa1af4340832f8943f0b3d8e9f2de11b1b1"
+SRCREV_machine_pn-linux-yocto_atom-pc = "f6454fa1af4340832f8943f0b3d8e9f2de11b1b1"
+SRCREV_machine_pn-linux-yocto_routerstationpro = "f0d79e2ae0cbb3924c57655b8c7d6a1276c9fc05"
+SRCREV_machine_pn-linux-yocto_mpc8315e-rdb = "a0243e84c1cca7fb625ae4bd76274882ccbe4333"
+SRCREV_machine_pn-linux-yocto_beagleboard = "f6454fa1af4340832f8943f0b3d8e9f2de11b1b1"
+SRCREV_meta_pn-linux-yocto ?= "7ca94548e68a72e57715d65d6d8f723582aafa59"
+SRCREV_pn-linux-libc-headers-yocto ??= "f6454fa1af4340832f8943f0b3d8e9f2de11b1b1"
SRCREV_pn-matchbox-config-gtk ??= "2081"
SRCREV_pn-matchbox-desktop-sato ??= "76"
SRCREV_pn-matchbox-desktop ??= "2096"
--
1.7.0.4


[PATCH 2/3] qemu: match kernel headers to preferred kernel

Bruce Ashfield <bruce.ashfield@...>
 

As the yocto-kernel advances, the libc headers must also
advance. This commit fixes the SRC_URI and SRCPV to work
properly with the latest linux-yocto kernel. It also switches
the qemu* targets to prefer this libc recipe.

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
meta/conf/machine/include/qemu.inc | 2 +-
.../linux-libc-headers-yocto_git.bb | 10 ++++------
2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/meta/conf/machine/include/qemu.inc b/meta/conf/machine/include/qemu.inc
index 502e24f..d762d01 100644
--- a/meta/conf/machine/include/qemu.inc
+++ b/meta/conf/machine/include/qemu.inc
@@ -16,6 +16,6 @@ RDEPENDS_kernel-base = ""

# Use a common kernel recipe for all QEMU machines
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
-#PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"
+PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"

EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb
index 0515233..762b6a8 100644
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb
@@ -6,14 +6,12 @@ B = "${S}"
INHIBIT_DEFAULT_DEPS = "1"
DEPENDS += "unifdef-native"
PROVIDES = "linux-libc-headers"
-PV = "2.6.34+git-${SRCPV}"
-PR = "r1"
-
-SRC_URI = "git://git.pokylinux.org/linux-2.6-windriver.git;fullclone=1"
+PV = "2.6.37+git-${SRCPV}"
+PR = "r2"

SRCREV_FORMAT = "meta_machine"
-SRC_URI = "git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;fullclone=1;branch=${KBRANCH};name=machine \
- git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;noclone=1;branch=wrs_meta;name=meta"
+SRC_URI = "git://git.pokylinux.org/linux-yocto-2.6.37;protocol=git;fullclone=1;branch=${KBRANCH};name=machine \
+ git://git.pokylinux.org/linux-yocto-2.6.37;protocol=git;noclone=1;branch=meta;name=meta"

set_arch() {
case ${TARGET_ARCH} in
--
1.7.0.4


[PATCH 1/3] linux-yocto-stable: fix qemux86 branch name

Bruce Ashfield <bruce.ashfield@...>
 

The mapping of qemu to kernel branch name for the stable
kernel had a small leak from the devel kernel. Nothing
broke since qemux86 prefers the 2.6.37 kernel and this was
hidden.

This fixes the mapping for anyone who does want a 2.6.34 based
qemux86 kernel.

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
.../recipes-kernel/linux/linux-yocto-stable_git.bb | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-stable_git.bb b/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
index 85b67f4..2f6eb2d 100644
--- a/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
@@ -1,7 +1,7 @@
inherit kernel
require linux-yocto.inc

-KMACHINE_qemux86 = "common_pc/base"
+KMACHINE_qemux86 = "common_pc"
KMACHINE_qemux86-64 = "common_pc_64"
KMACHINE_qemuppc = "qemu_ppc32"
KMACHINE_qemumips = "mti_malta32_be"
--
1.7.0.4


[PATCH 0/3] linux-yocto: update to 2.6.37-rc6 and minor fixes

Bruce Ashfield <bruce.ashfield@...>
 

Richard/Saul,

This fixes BUGID #596 (mouse in qemuarm), through the fixing of
the linux-libc-headers-yocto recipe. The mouse was broken due to
tslib being out of sync with the kernel and not activating the
pointer. Having the matching kernel headers fixes this problem.

** Note: I saw some instances where I was getting fetcher/unpack
errors during my testing of this. I wasn't able to consistently
reproduce the error, so I wasn't able to conclusively determine if
it has anything to do with the libc-headers change. I recommend
that we watch this carefully and be prepared to revert as required
(revert the headers preference in qemu.inc).

This also updating the SRCREVs of the target branches in the linux-yocto
development kernel to point to 2.6.37-rc6 content.

And finally, this updates the meta branch to remove the rest of the _'s
from branch meta data. At this point branches have been switched
from _ to - and we are able to remove the old branch names. (which
I have done).

Pull URL: git://git.pokylinux.org/poky-contrib.git
Branch: zedd/kernel
Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Thanks,
Bruce Ashfield <bruce.ashfield@...>
---


Bruce Ashfield (3):
linux-yocto-stable: fix qemux86 branch name
qemu: match kernel headers to preferred kernel
linux-yocto: update to 2.6.37-rc6

.../conf/distro/include/poky-default-revisions.inc | 26 ++++++++++----------
meta/conf/machine/include/qemu.inc | 2 +-
.../linux-libc-headers-yocto_git.bb | 10 +++----
.../recipes-kernel/linux/linux-yocto-stable_git.bb | 2 +-
4 files changed, 19 insertions(+), 21 deletions(-)


Yocto weekly bug trend charts -- WW51

Xu, Jiajun <jiajun.xu@...>
 

Hi all,
This is latest Yocto bug trend chart. QA started M2 testing from last week. Open bug number raised a little to 157.

Best Regards,
Jiajun


Re: Yocto Bugzilla will be rebuild today

Saul Wold <sgw@...>
 

On 12/21/2010 06:19 AM, You, Yongkang wrote:
Hi all,

Bugzilla structure is completely rebuilt. It can accept new bug updating and reporting.

Please visit http://bugzilla.pokylinux.org/show_bug.cgi?id=564 to get detailed changing.

A fake user list is also added for catching bug update in time. https://wiki.yoctoproject.org/wiki/Watch_Yocto_Bugs
Thanks for doing the major reorg!

Sau!

Thanks,
Yongkang


On Tuesday, December 21, 2010 11:45 AM, yocto-bounces@...
wrote:
Hi all,

I will remotely reconstruct bugzilla to align new Yocto
structure today. The detailed info can be found at
http://bugzilla.pokylinux.org/show_bug.cgi?id=564

I am planning to change bugzilla start from UTS 5 a.m.
(2010-12-21) and sending another email when finishing. I will
also disable bugzilla sendmail function.

Please hold on any bug's modification, until see my update. Thanks
for supporting.

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


What hosts do we support?

deVries, Alex <Alex.deVries@...>
 

I think we're at the point where we should think of what makes a host supported, and what expectations we have of that host. The situation is undocumented and a bit frustrating today.

It should be really easy to get going with YML/poky. We should consider optimizing the following workflow:
1. Install a minimal distribution
2. Download YML/poky, run it
3. Follow only the instructions provided
4. Complete a build

It may be required that the user has root access temporarily to update packages. Only packages provided by the distribution vendor should need to be installed. The user should only have to make changes once. The need for these changes should be minimized.

Yocto can then advertise a finite list of supported distributions, with the goal of widening the list over time.

Feedback? Are these reasonable guidelines?


- A


Ideas for yoctoproject.org improvements

David Stewart
 

Hello Yocto Project –

 

I was asked yesterday what kinds of things we might do to improve the project website, http://www.yoctoproject.org – I have a few opinions on the subject, but I thought I would put the question to you.

 

Where can we do better? What kinds of frustrations did you have with the site when you first got involved with the project? How could it improve the experience of people becoming familiar with the project?

 

If you want to use this email thread, that would be great. Or if you prefer to file issues in bugzilla.yoctoproject.org, that would be great too.


Thanks!

 

Dave


[PATCH 3/3] Change to poky-autobuild to source correct file:

Elizabeth Flanagan <elizabeth.flanagan@...>
 

A change to poky-init-build-env in poky master broke the autobuilder.
Switching this to source poky-init-build-env instead of
poky-env-internal.

Signed-off-by: Beth Flanagan <elizabeth.flanagan@...>
---
scripts/poky-autobuild | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/scripts/poky-autobuild b/scripts/poky-autobuild
index 5ea61bb..882df97 100755
--- a/scripts/poky-autobuild
+++ b/scripts/poky-autobuild
@@ -32,7 +32,7 @@ cd $CURRDIR
echo "Changed to $CURRDIR"

BDIR="build"
-. ./scripts/poky-env-internal
+. ./scripts/poky-init-build-env
POSTPROCESS=`which poky-autobuild-postprocess`

if [ "xcomplete" = "x$1" ]; then
-- 1.7.1