Date   

Re: Personal git repositories

Richard Purdie
 

On Wed, 2011-04-27 at 20:59 -0400, Bruce Ashfield wrote:
On 11-04-27 6:47 PM, Darren Hart wrote:
I don't understand wanting to keep multiple distinct source trees in a single
git repositorie. If you have two different layers in there, each in its own
branch, then you can only work with one of them at a time. The end-user then has
to have multiple clones of the same repository in order to work with their two
layers. And they will end up naming them something like:

yocto-contrib-layer-1.git
yocto-contrib-layer-2.git
This is what I was wondering as well. I had my meta-kernel-dev as
a branch on poky-extras and ran into exactly this problem. Either
have two clones, or get it into master. Master was the choice, since
the other seemed clunky.

Maybe I'm misunderstanding as well, but sparse fetch or not (and
yes I've done/used it), logically I like things that are distinct
source trees to be separate repos. Maybe it's a kernel-guy thing ? :)
I think there are three elements to this:

a) People do like the logical separation that a repo gives them and
find it easiest to think in those terms.
b) Most people are used to single relatively monolithic repos such as
the kernel. People like myself who have used svn with multiple
projects contained within like matchbox or the OpenedHand "misc" svn
repo or the BSD projects approach to source control are probably in
the minority.
c) The git tooling and all the examples out there are geared up to
single repos. git is very much a tool where you need to think as its
authors do.

Some of this can be addressed with clear example documentation about how
to use git in this way.

Partly, these proposals are also working within the constraints of the
git server solution we have too. Are we really in such a bad position
that we need to change all the server setup over this or are there ways
we can work within the existing system (or even extend gitolite)?

Cheers,

Richard


(No subject)

Liping Ke <liping.ke@...>
 

From: Liping Ke <liping.ke@...>

Subject: [PATCH 1/1] Resend:[Image-Creator]Make bitbake server type configurable (xmlrpc, none)

Add -t options in bitbake for configuring server type.

Signed-off-by: Liping Ke <liping.ke@...>
---
bitbake/bin/bitbake | 22 +++++++++++++++++-----
1 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/bitbake/bin/bitbake b/bitbake/bin/bitbake
index 6d05289..2c45224 100755
--- a/bitbake/bin/bitbake
+++ b/bitbake/bin/bitbake
@@ -39,8 +39,6 @@ import bb.msg
from bb import cooker
from bb import ui
from bb import server
-from bb.server import none
-#from bb.server import xmlrpc

__version__ = "1.11.0"
logger = logging.getLogger("BitBake")
@@ -71,7 +69,7 @@ def get_ui(config):
return getattr(module, interface).main
except AttributeError:
sys.exit("FATAL: Invalid user interface '%s' specified.\n"
- "Valid interfaces: depexp, goggle, ncurses, knotty [default]." % interface)
+ "Valid interfaces: depexp, goggle, ncurses, hob, knotty [default]." % interface)


# Display bitbake/OE warnings via the BitBake.Warnings logger, ignoring others"""
@@ -161,6 +159,9 @@ Default BBFILES are the .bb files in the current directory.""")
parser.add_option("-u", "--ui", help = "userinterface to use",
action = "store", dest = "ui")

+ parser.add_option("-t", "--servertype", help = "choose which server to user, none or xmlrpc",
+ action = "store", dest = "servertype")
+
parser.add_option("", "--revisions-changed", help = "Set the exit code depending on whether upstream floating revisions have changed or not",
action = "store_true", dest = "revisions_changed", default = False)

@@ -175,8 +176,19 @@ Default BBFILES are the .bb files in the current directory.""")
loghandler = event.LogHandler()
logger.addHandler(loghandler)

- #server = bb.server.xmlrpc
- server = bb.server.none
+ # Server type could be xmlrpc or none currently, if nothing is specified,
+ # default server would be none
+ if configuration.servertype:
+ server_type = configuration.servertype
+ else:
+ server_type = 'none'
+
+ try:
+ module = __import__("bb.server", fromlist = [server_type])
+ server = getattr(module, server_type)
+ except AttributeError:
+ sys.exit("FATAL: Invalid server type '%s' specified.\n"
+ "Valid interfaces: xmlrpc [default]." % servertype)

# Save a logfile for cooker into the current working directory. When the
# server is daemonized this logfile will be truncated.
--
1.7.0.4


[PATCH 0/1] Resend:[Image-Creator]Make bitbake server type configurable (xmlrpc, none)

Liping Ke <liping.ke@...>
 

From: Liping Ke <liping.ke@...>

Add -t options in bitbake for configuring server type.

Signed-off-by: Liping Ke <liping.ke@...>


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

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


Liping Ke (1):
Make bitbake server type configurable (xmlrpc, none)

bitbake/bin/bitbake | 22 +++++++++++++++++-----
1 files changed, 17 insertions(+), 5 deletions(-)


Re: Personal git repositories

Xianghua Xiao <xiaoxianghua@...>
 

most if not all meego repo is on gitorious, why can't Yocto leverage
it, at least for now while everything is changing fast?

Xianghua

On Wed, Apr 27, 2011 at 7:59 PM, Bruce Ashfield
<bruce.ashfield@...> wrote:
On 11-04-27 6:47 PM, Darren Hart wrote:

On 04/27/2011 02:03 PM, Richard Purdie wrote:

On Wed, 2011-04-27 at 10:20 -0700, Elizabeth Flanagan wrote:

A few notes, since I talked with Darren about this earlier.

As one of the people in charge of maintaining the git repo, I would like
to
avoid having, as Darren suggested, a whole bunch of -contrib repos.
However,
maybe I'm missing something here, as I think basic git solves this
issue:

Use Case: Tomz has a branch of meta-intel that he has pushed to
poky-contrib.git:tomz/foo. dvhart wants to look at it from his local
repo:
I'm curious how many people reading this feel this is "basic git". Anyone
willing to admit this was the first time they have seen a targeted branch
fetch used to avoid a larger download? If everyone is comfortable with
this,
fine. If not, we should consider the impact of this type of access on our
users.

git remote add poky-contrib ssh://git@.../poky-contrib.git
git fetch poky-contrib tomz/foo:foo
git checkout foo
My biggest complaint with this is the lack of self discovery from within
git
without doing a git remote update. Unless tomz is online at the time to
tell me
it's tomz/foo-bar, not tomz/foo_bar, then I have to go load the web
browser and
check which branches are available, or resort to downloading all the
objects.


I confess though, it still just feels wrong to keep unrelated source trees
in
the same repository.


The fetch allows a sparse checkout of *just* tomz's branch. No need to
download all 75M of poky-contrib which is what you would do with "git
remote
update". Git remote update is the wrong way to do this and I'd like to
avoid
having to swap infrastructure around when it seems to me that this is
just
one of those "git being a pain to learn"
Just to add to this discussion, with gitolite, it should be easy to
setup a yocto-contrib repo where each user "owns" the branches under
<keyname>/*. This means as ssh keys are added, they'd automatically get
their own "scratch" area. As Beth points out above, its perfectly
possible to checkout branches and manipulate them as long as you know
the commands.

This isn't a set of repos per user but when you think about this, how
often do we really need that? Yes, some people like Bruce have usecases
but I'm not sure they're typical and in those small number of cases I'm
sure we can come up with some generic testing/dev repos to assist too.
As soon as something grows to the point where the branch is problematic,
it deserves its own repo and it should be properly namespaced, not user
specific anyway.

I don't understand wanting to keep multiple distinct source trees in a
single
git repositorie. If you have two different layers in there, each in its
own
branch, then you can only work with one of them at a time. The end-user
then has
to have multiple clones of the same repository in order to work with their
two
layers. And they will end up naming them something like:

yocto-contrib-layer-1.git
yocto-contrib-layer-2.git
This is what I was wondering as well. I had my meta-kernel-dev as
a branch on poky-extras and ran into exactly this problem. Either
have two clones, or get it into master. Master was the choice, since
the other seemed clunky.

Maybe I'm misunderstanding as well, but sparse fetch or not (and
yes I've done/used it), logically I like things that are distinct
source trees to be separate repos. Maybe it's a kernel-guy thing ? :)

Cheers,

Bruce


And keep them checked out to the appropriate set of branches... that seems
like
a lot of pain to impose on users to avoid setting up personal git
repositories.
Personally, I think I would revert to my kernel.org repositories rather
than try
and make this work.

Or - is my git-fu weak? Is there a better way to handle the above?
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Yocto Schedule at-a-glance now on schedule wiki

Fleischer, Julie N <julie.n.fleischer@...>
 

FYI - If you'd like to view the Yocto schedule at-a-glance, see the file linked to at the top of the Yocto schedule Wiki: https://wiki.yoctoproject.org/wiki/Yocto_1.1_Schedule.

- Julie

-----------------------
Julie Fleischer
Open Source Technology Center
Intel Corporation


Re: Personal git repositories

Bruce Ashfield <bruce.ashfield@...>
 

On 11-04-27 6:47 PM, Darren Hart wrote:
On 04/27/2011 02:03 PM, Richard Purdie wrote:
On Wed, 2011-04-27 at 10:20 -0700, Elizabeth Flanagan wrote:
A few notes, since I talked with Darren about this earlier.

As one of the people in charge of maintaining the git repo, I would like to
avoid having, as Darren suggested, a whole bunch of -contrib repos. However,
maybe I'm missing something here, as I think basic git solves this issue:

Use Case: Tomz has a branch of meta-intel that he has pushed to
poky-contrib.git:tomz/foo. dvhart wants to look at it from his local repo:
I'm curious how many people reading this feel this is "basic git". Anyone
willing to admit this was the first time they have seen a targeted branch
fetch used to avoid a larger download? If everyone is comfortable with this,
fine. If not, we should consider the impact of this type of access on our
users.

git remote add poky-contrib ssh://git@.../poky-contrib.git
git fetch poky-contrib tomz/foo:foo
git checkout foo
My biggest complaint with this is the lack of self discovery from within git
without doing a git remote update. Unless tomz is online at the time to tell me
it's tomz/foo-bar, not tomz/foo_bar, then I have to go load the web browser and
check which branches are available, or resort to downloading all the objects.


I confess though, it still just feels wrong to keep unrelated source trees in
the same repository.


The fetch allows a sparse checkout of *just* tomz's branch. No need to
download all 75M of poky-contrib which is what you would do with "git remote
update". Git remote update is the wrong way to do this and I'd like to avoid
having to swap infrastructure around when it seems to me that this is just
one of those "git being a pain to learn"
Just to add to this discussion, with gitolite, it should be easy to
setup a yocto-contrib repo where each user "owns" the branches under
<keyname>/*. This means as ssh keys are added, they'd automatically get
their own "scratch" area. As Beth points out above, its perfectly
possible to checkout branches and manipulate them as long as you know
the commands.

This isn't a set of repos per user but when you think about this, how
often do we really need that? Yes, some people like Bruce have usecases
but I'm not sure they're typical and in those small number of cases I'm
sure we can come up with some generic testing/dev repos to assist too.
As soon as something grows to the point where the branch is problematic,
it deserves its own repo and it should be properly namespaced, not user
specific anyway.

I don't understand wanting to keep multiple distinct source trees in a single
git repositorie. If you have two different layers in there, each in its own
branch, then you can only work with one of them at a time. The end-user then has
to have multiple clones of the same repository in order to work with their two
layers. And they will end up naming them something like:

yocto-contrib-layer-1.git
yocto-contrib-layer-2.git
This is what I was wondering as well. I had my meta-kernel-dev as
a branch on poky-extras and ran into exactly this problem. Either
have two clones, or get it into master. Master was the choice, since
the other seemed clunky.

Maybe I'm misunderstanding as well, but sparse fetch or not (and
yes I've done/used it), logically I like things that are distinct
source trees to be separate repos. Maybe it's a kernel-guy thing ? :)

Cheers,

Bruce


And keep them checked out to the appropriate set of branches... that seems like
a lot of pain to impose on users to avoid setting up personal git repositories.
Personally, I think I would revert to my kernel.org repositories rather than try
and make this work.

Or - is my git-fu weak? Is there a better way to handle the above?


Re: Personal git repositories

Darren Hart <darren.hart@...>
 

On 04/27/2011 02:03 PM, Richard Purdie wrote:
On Wed, 2011-04-27 at 10:20 -0700, Elizabeth Flanagan wrote:
A few notes, since I talked with Darren about this earlier.

As one of the people in charge of maintaining the git repo, I would like to
avoid having, as Darren suggested, a whole bunch of -contrib repos. However,
maybe I'm missing something here, as I think basic git solves this issue:

Use Case: Tomz has a branch of meta-intel that he has pushed to
poky-contrib.git:tomz/foo. dvhart wants to look at it from his local repo:
I'm curious how many people reading this feel this is "basic git". Anyone
willing to admit this was the first time they have seen a targeted branch
fetch used to avoid a larger download? If everyone is comfortable with this,
fine. If not, we should consider the impact of this type of access on our
users.

git remote add poky-contrib ssh://git@.../poky-contrib.git
git fetch poky-contrib tomz/foo:foo
git checkout foo
My biggest complaint with this is the lack of self discovery from within git
without doing a git remote update. Unless tomz is online at the time to tell me
it's tomz/foo-bar, not tomz/foo_bar, then I have to go load the web browser and
check which branches are available, or resort to downloading all the objects.


I confess though, it still just feels wrong to keep unrelated source trees in
the same repository.


The fetch allows a sparse checkout of *just* tomz's branch. No need to
download all 75M of poky-contrib which is what you would do with "git remote
update". Git remote update is the wrong way to do this and I'd like to avoid
having to swap infrastructure around when it seems to me that this is just
one of those "git being a pain to learn"
Just to add to this discussion, with gitolite, it should be easy to
setup a yocto-contrib repo where each user "owns" the branches under
<keyname>/*. This means as ssh keys are added, they'd automatically get
their own "scratch" area. As Beth points out above, its perfectly
possible to checkout branches and manipulate them as long as you know
the commands.

This isn't a set of repos per user but when you think about this, how
often do we really need that? Yes, some people like Bruce have usecases
but I'm not sure they're typical and in those small number of cases I'm
sure we can come up with some generic testing/dev repos to assist too.
As soon as something grows to the point where the branch is problematic,
it deserves its own repo and it should be properly namespaced, not user
specific anyway.

I don't understand wanting to keep multiple distinct source trees in a single
git repositorie. If you have two different layers in there, each in its own
branch, then you can only work with one of them at a time. The end-user then has
to have multiple clones of the same repository in order to work with their two
layers. And they will end up naming them something like:

yocto-contrib-layer-1.git
yocto-contrib-layer-2.git

And keep them checked out to the appropriate set of branches... that seems like
a lot of pain to impose on users to avoid setting up personal git repositories.
Personally, I think I would revert to my kernel.org repositories rather than try
and make this work.

Or - is my git-fu weak? Is there a better way to handle the above?

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


Re: Personal git repositories

Richard Purdie
 

On Wed, 2011-04-27 at 10:20 -0700, Elizabeth Flanagan wrote:
A few notes, since I talked with Darren about this earlier.

As one of the people in charge of maintaining the git repo, I would like to avoid having, as Darren suggested, a whole
bunch of -contrib repos. However, maybe I'm missing something here, as I think basic git solves this issue:

Use Case: Tomz has a branch of meta-intel that he has pushed to poky-contrib.git:tomz/foo. dvhart wants to look at it
from his local repo:

git remote add poky-contrib ssh://git@.../poky-contrib.git
git fetch poky-contrib tomz/foo:foo
git checkout foo

The fetch allows a sparse checkout of *just* tomz's branch. No need to download all 75M of poky-contrib which is what
you would do with "git remote update". Git remote update is the wrong way to do this and I'd like to avoid having to
swap infrastructure around when it seems to me that this is just one of those "git being a pain to learn"
Just to add to this discussion, with gitolite, it should be easy to
setup a yocto-contrib repo where each user "owns" the branches under
<keyname>/*. This means as ssh keys are added, they'd automatically get
their own "scratch" area. As Beth points out above, its perfectly
possible to checkout branches and manipulate them as long as you know
the commands.

This isn't a set of repos per user but when you think about this, how
often do we really need that? Yes, some people like Bruce have usecases
but I'm not sure they're typical and in those small number of cases I'm
sure we can come up with some generic testing/dev repos to assist too.
As soon as something grows to the point where the branch is problematic,
it deserves its own repo and it should be properly namespaced, not user
specific anyway.

Cheers,

Richard


Re: Personal git repositories

Elizabeth Flanagan <elizabeth.flanagan@...>
 

On 04/27/2011 11:14 AM, Joshua Lock wrote:
On Wed, 2011-04-27 at 10:20 -0700, Elizabeth Flanagan wrote:
A few notes, since I talked with Darren about this earlier.

As one of the people in charge of maintaining the git repo, I would like to avoid having, as Darren suggested, a whole
bunch of -contrib repos. However, maybe I'm missing something here, as I think basic git solves this issue:
I don't agree. I have a few sparse layers and some other code that I am
not sharing because they need repositories *somewhere*.
Different use case from what I'm seeing as the general concern, however, I would say that if someone has code that doesn't belong in oe-core but it's standalone and useful to the project, then you would put in a request to have a new repo added. And maybe that's a good argument for new infrastructure if the current process doesn't scale well (which I don't have data that would come to any conclusion like that).

Having said that some of these recipes may be useful to others yet
definitely don't belong in oe-core. What do I do with them? The
mechanism Darren describes seems like it would work for my use case.
Ask me to create a repo. If I was getting a flood of repo creation requests or there was a use case that was compelling, I'd be on board with this in a heartbeat, but to me, it just seems like it's better served by people understanding the process better.

The current process is to send me an email (ccing RP), saying what repo you want, why you need it and then we go from there and create it, if it makes sense. I think I'm specifically worried less about your use case (I get *maybe* a repo request a month) than I am about people justifying an infrastructure change in order to have a whole bunch of contrib repos. That is better served by sparse fetches of needed branches from poky-contrib.


---------------
Elizabeth Flanagan
Yocto Project
Release Engineer


Re: Personal git repositories

Joshua Lock <josh@...>
 

On Wed, 2011-04-27 at 10:20 -0700, Elizabeth Flanagan wrote:
A few notes, since I talked with Darren about this earlier.

As one of the people in charge of maintaining the git repo, I would like to avoid having, as Darren suggested, a whole
bunch of -contrib repos. However, maybe I'm missing something here, as I think basic git solves this issue:
I don't agree. I have a few sparse layers and some other code that I am
not sharing because they need repositories *somewhere*.

Having said that some of these recipes may be useful to others yet
definitely don't belong in oe-core. What do I do with them? The
mechanism Darren describes seems like it would work for my use case.

Cheers,
Joshua
--
Joshua Lock
Yocto Build System Monkey
Intel Open Source Technology Centre


Re: Personal git repositories

Elizabeth Flanagan <elizabeth.flanagan@...>
 

A few notes, since I talked with Darren about this earlier.

As one of the people in charge of maintaining the git repo, I would like to avoid having, as Darren suggested, a whole bunch of -contrib repos. However, maybe I'm missing something here, as I think basic git solves this issue:

Use Case: Tomz has a branch of meta-intel that he has pushed to poky-contrib.git:tomz/foo. dvhart wants to look at it from his local repo:

git remote add poky-contrib ssh://git@.../poky-contrib.git
git fetch poky-contrib tomz/foo:foo
git checkout foo

The fetch allows a sparse checkout of *just* tomz's branch. No need to download all 75M of poky-contrib which is what you would do with "git remote update". Git remote update is the wrong way to do this and I'd like to avoid having to swap infrastructure around when it seems to me that this is just one of those "git being a pain to learn"

-b

On 04/27/2011 07:45 AM, Darren Hart wrote:


On 04/27/2011 12:56 AM, Koen Kooi wrote:

Op 27 apr 2011, om 05:00 heeft Darren Hart het volgende geschreven:

git.yoctoproject.org hosts a number of different repositories, some of
which host limited user contributions (such as poky-contrib). These
repositories are setup and administered by a yoctoproject.org system admin.

As our developer base grows, the need for user creatable git trees also
grows. Eventually, *-contrib isn't going to scale, and neither will the
system admin. There are plenty of available places individuals can
create publicly accessible trees (github, kernel.org, or any number of
similar sites). However, I think it would be beneficial for at least
very active developers to be able to create and destroy trees on a whim,
without having to involve the system admin with each event.

kernel.org provides a git web interface for user created trees. I'd like
to see something similar available at yoctoproject.org in order to
establish single place to go looking for "yocto developer trees". Users
would have to justify their request for a user account and agree to a
terms of use. This has served the Linux kernel community very well. I
think it could do the same for us.

Note: I am not offering to setup such a service or even say that it's
possible with the current resources. I just wanted to throw the idea out
there and see if others have found a similar gap in the development
environment and if this idea would address that gap.

Have you though about setting up a gitorious instance on git.yocto?
I think that is a fantastic idea, it gets my vote.

gitorious++

--
---------------
Elizabeth Flanagan
Yocto Project
Release Engineer


Weekly Test Report for Yocto 20110423 Build

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

Hi all,

       This is the weekly test report for Yocto 20110423 build. All meta-intel BSP build are failed on autobuilder. A new boot up failure bug is found on both routerstationpro and mpc8315e-rdb. The zypper/rpm status is same as previous testing result that .all package could not be installed.

       For bug fixing, only one build bug is fixed for mpc8315e-rdb.

 

Test Summary

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

Test Result Summary

 

Component

Target

Status

Comments

 

BSP

SugarBay

BLOCK

Build failed

 

 

CrownBay

BLOCK

Build failed

 

 

JasperForest

BLOCK

Build failed

 

 

Blacksand

BLOCK

Build failed

 

 

Beagleboard

n/a

No test due to test board broken

 

 

Routerstationpro

BLOCK

Rootfs boot failed;

 

 

Mpc8315e-rdb

BLOCK

Rootfs boot failed;

 

QEMU

qemux86

GOOD

Everything runs well except for zypper install with .all package

 

 

qemux86-64

GOOD

Same as above

 

 

qemuarm

GOOD

Same as above

 

 

qemuppc

GOOD

Same as above

 

 

qemumips

GOOD

Same as above

 

SDK

 

Buggy

unfs does not work with qemuppc

 

 

 

Critical bugs, more than 50% test cases are blocked

 

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

 

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

 

Detailed Test Result for each component

Target

Total TCs

Not Run

Passed

Failed

Not testable (Blocked)

Qemux86-64 Sato

21

0

20

1(bug 993)

0

Qemux86-64 Sato-SDK

24

0

23

1(bug 993)

0

Qemux86 Sato

21

0

20

1(bug 993)

0

Qemux86 Sato-SDK

24

0

23

1(bug 993)

0

Qemumips Sato

21

0

20

1(bug 993)

0

Qemumips Sato-SDK

24

0

23

1(bug 993)

0

Qemuppc Sato

18

0

17

1(bug 993)

0

Qemuppc Sato-SDK

21

0

20

1(bug 993)

0

Qemuarm Sato

21

0

20

1(bug 993)

0

Qemuarm Sato-SDK

24

0

23

1(bug 993)

0

SDK

3

0

2

1 (bug 414)

0

Total

222

0

211

11

0

 

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

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

 

Images

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

Image: http://autobuilder.pokylinux.org/nightly/20110423-1/

Tree/Branch: contrib/master_under_test

Commit: 653cd1423793a3fd66da5c5682021d5c5b729cfe

 

Issue Summary

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

Zypper:

1.     [zypper] zypper can not install packages which from 'all' directory in repository

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

 

SDK:

1.     [PPC] kernel panic when booting poky-image-sdk-qemuppc through UNFS

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

 

BSP/Build:

1.     New! [mpc8315e-rdb & routerstationpro] minimal,sato,sato-sdk images boot failed (nightly build 20110423-1)

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

 

Others:

1.     qemuarm cannot shutdown entirely through UNFS

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

 

Verified Fixed Bugs:

1.     autobuilder build failed for mpc8315e-rdb lsb in nightly build (20110412-1)

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

 

 

Best Regards,

Jiajun


Re: Personal git repositories

Darren Hart <dvhart@...>
 

On 04/27/2011 12:56 AM, Koen Kooi wrote:

Op 27 apr 2011, om 05:00 heeft Darren Hart het volgende geschreven:

git.yoctoproject.org hosts a number of different repositories, some of
which host limited user contributions (such as poky-contrib). These
repositories are setup and administered by a yoctoproject.org system admin.

As our developer base grows, the need for user creatable git trees also
grows. Eventually, *-contrib isn't going to scale, and neither will the
system admin. There are plenty of available places individuals can
create publicly accessible trees (github, kernel.org, or any number of
similar sites). However, I think it would be beneficial for at least
very active developers to be able to create and destroy trees on a whim,
without having to involve the system admin with each event.

kernel.org provides a git web interface for user created trees. I'd like
to see something similar available at yoctoproject.org in order to
establish single place to go looking for "yocto developer trees". Users
would have to justify their request for a user account and agree to a
terms of use. This has served the Linux kernel community very well. I
think it could do the same for us.

Note: I am not offering to setup such a service or even say that it's
possible with the current resources. I just wanted to throw the idea out
there and see if others have found a similar gap in the development
environment and if this idea would address that gap.

Have you though about setting up a gitorious instance on git.yocto?
I think that is a fantastic idea, it gets my vote.

gitorious++


--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


[RFC] fix seg fault of evolution-data-server when adding default vcard

Zhai, Edwin <edwin.zhai@...>
 

This is one simple patch to fix seg fault of evolution-data-server,
when new contact is added for new created DB.

The root cause is simple: do_create (bf, XIMIAN_VCARD,....) would access
bf->priv->file_db and cause seg fault if not initialized.

I have created one bz https://bugzilla.gnome.org/show_bug.cgi?id=648736, also attached patch for comments.


=====================================
Adding default vcard for new created DB always failed with seg fault, as
file_db was not initialized before access. This patch fix it.

Signed-off-by: Edwin Zhai <edwin.zhai@...>
Index: evolution-data-server/addressbook/backends/file/e-book-backend-file.c
===================================================================
---
evolution-data-server.orig/addressbook/backends/file/e-book-backend-file.c

2011-04-26 15:46:03.000000000 +0800
+++
evolution-data-server/addressbook/backends/file/e-book-backend-file.c 2011-04-26 15:59:13.000000000 +0800
@@ -1247,6 +1247,8 @@
#ifdef CREATE_DEFAULT_VCARD
EContact *contact = NULL;

+ /* Initialize file_db, or else following do_create
cause seg fault */
+ bf->priv->file_db = db;
if (!do_create (bf, XIMIAN_VCARD, &contact, NULL))
g_warning ("Cannot create default contact");
if (contact)


------------------------
Yocto Project @
http://www.yoctoproject.org/


Re: Personal git repositories

Koen Kooi
 

Op 27 apr 2011, om 05:00 heeft Darren Hart het volgende geschreven:

git.yoctoproject.org hosts a number of different repositories, some of
which host limited user contributions (such as poky-contrib). These
repositories are setup and administered by a yoctoproject.org system admin.

As our developer base grows, the need for user creatable git trees also
grows. Eventually, *-contrib isn't going to scale, and neither will the
system admin. There are plenty of available places individuals can
create publicly accessible trees (github, kernel.org, or any number of
similar sites). However, I think it would be beneficial for at least
very active developers to be able to create and destroy trees on a whim,
without having to involve the system admin with each event.

kernel.org provides a git web interface for user created trees. I'd like
to see something similar available at yoctoproject.org in order to
establish single place to go looking for "yocto developer trees". Users
would have to justify their request for a user account and agree to a
terms of use. This has served the Linux kernel community very well. I
think it could do the same for us.

Note: I am not offering to setup such a service or even say that it's
possible with the current resources. I just wanted to throw the idea out
there and see if others have found a similar gap in the development
environment and if this idea would address that gap.

Have you though about setting up a gitorious instance on git.yocto?

Regards,

Koen


Re: Personal git repositories

Darren Hart <dvhart@...>
 

On 04/26/2011 10:05 PM, Tom Zanussi wrote:
On Tue, 2011-04-26 at 21:53 -0700, Darren Hart wrote:

On 04/26/2011 09:39 PM, Tom Zanussi wrote:
On Tue, 2011-04-26 at 20:00 -0700, Darren Hart wrote:
git.yoctoproject.org hosts a number of different repositories, some of
which host limited user contributions (such as poky-contrib). These
repositories are setup and administered by a yoctoproject.org system admin.

As our developer base grows, the need for user creatable git trees also
grows. Eventually, *-contrib isn't going to scale, and neither will the
system admin. There are plenty of available places individuals can
create publicly accessible trees (github, kernel.org, or any number of
similar sites). However, I think it would be beneficial for at least
very active developers to be able to create and destroy trees on a whim,
without having to involve the system admin with each event.

kernel.org provides a git web interface for user created trees. I'd like
to see something similar available at yoctoproject.org in order to
establish single place to go looking for "yocto developer trees". Users
would have to justify their request for a user account and agree to a
terms of use. This has served the Linux kernel community very well. I
think it could do the same for us.

Note: I am not offering to setup such a service or even say that it's
possible with the current resources. I just wanted to throw the idea out
there and see if others have found a similar gap in the development
environment and if this idea would address that gap.

Thoughts?
My thinking (I guess - I didn't really think that much about it at the
time) when requesting the meta-intel-contrib repo was that repos that
could expect to get continual contributions from many people would
benefit from having a corresponding -contrib version - so far that's
poky-contrib, linux-yocto-*.contrib, and openembedded-core-contrib. To
me bsp repos fit the same criteria, but I'm not the one who has to
manage it all, so I understand the desire to avoid the proliferation.

Seems like the personal repos idea would mitigate the problem...
I think these are two distinct but overlapping problems:

1) place to share on the common core (poky, linux-yocto*)
2) place to share new stuff that may not amount to anything

For #1, the *-contrib git repositories make sense to me. It provides a
single repository that a lot of people use and reduces the git remote
management for everyone. They are therefor worth the added complexity
they add to the yoctoproject git namespace and on the system administrator.

For #2, people need to be able to prepare a tree and poke someone in IRC
with a git URL to try out. Many of these are likely to be short lived,
and to only have a single contributor. As such, they are not worth
polluting the yoctoproject git namespace, nor should we burden our
system admin with setting them up and tearing them down. Indeed, they
are likely to linger, continuing to pollute the namespace long after
they are dead trees simply due to the overhead of removing them!

As for BSP's... these don't seem to have a lot of contributors - at
least from what I have seen. Typically 1 or 2 people. For that scenario,
I see two processes as options:

a) add user branches:
master
bernard
dvhart/topicA
dvhart/topicB
tzanussi/topicA
tzanussi/topicD
Yeah, that's what you and I do already. But we now have people coming
online who will be be continually pushing changes to their bsps in
meta-intel and we don't necessarily want to give them write access to
meta-intel itself right away, I assume...

b) use the personal repositories described in #2 above
Yeah, so we could create and manage meta-intel-contrib ourselves without
bothering any admins...
Well, sort of. The personal trees would be writable only by their owner.
Otherwise you would have to manage all the user authentication. I forgot
about the new meta-intel contributors.

I would suggest we start with a pull model to get things upstream. As
they gain confidence in contributing, we can look at something where
they have more control of a repository, probably still will need a
meta-intel-contrib in this case.

--
Darren


Tom

While it is possible to use poky-contrib for things like this, I think
it is non-intuitive to use a repository as a remote to a repository that
isn't based off the remote repository (like BSP layers which aren't part
of poky). For most users, this will result in pulling down MBs of
unnecessary git objects. Yes, you can use --reference when cloning. Yes,
you can use fancy fetch commands. No, nobody will.

Thanks,
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


Re: Personal git repositories

Tom Zanussi <tom.zanussi@...>
 

On Tue, 2011-04-26 at 21:53 -0700, Darren Hart wrote:

On 04/26/2011 09:39 PM, Tom Zanussi wrote:
On Tue, 2011-04-26 at 20:00 -0700, Darren Hart wrote:
git.yoctoproject.org hosts a number of different repositories, some of
which host limited user contributions (such as poky-contrib). These
repositories are setup and administered by a yoctoproject.org system admin.

As our developer base grows, the need for user creatable git trees also
grows. Eventually, *-contrib isn't going to scale, and neither will the
system admin. There are plenty of available places individuals can
create publicly accessible trees (github, kernel.org, or any number of
similar sites). However, I think it would be beneficial for at least
very active developers to be able to create and destroy trees on a whim,
without having to involve the system admin with each event.

kernel.org provides a git web interface for user created trees. I'd like
to see something similar available at yoctoproject.org in order to
establish single place to go looking for "yocto developer trees". Users
would have to justify their request for a user account and agree to a
terms of use. This has served the Linux kernel community very well. I
think it could do the same for us.

Note: I am not offering to setup such a service or even say that it's
possible with the current resources. I just wanted to throw the idea out
there and see if others have found a similar gap in the development
environment and if this idea would address that gap.

Thoughts?
My thinking (I guess - I didn't really think that much about it at the
time) when requesting the meta-intel-contrib repo was that repos that
could expect to get continual contributions from many people would
benefit from having a corresponding -contrib version - so far that's
poky-contrib, linux-yocto-*.contrib, and openembedded-core-contrib. To
me bsp repos fit the same criteria, but I'm not the one who has to
manage it all, so I understand the desire to avoid the proliferation.

Seems like the personal repos idea would mitigate the problem...
I think these are two distinct but overlapping problems:

1) place to share on the common core (poky, linux-yocto*)
2) place to share new stuff that may not amount to anything

For #1, the *-contrib git repositories make sense to me. It provides a
single repository that a lot of people use and reduces the git remote
management for everyone. They are therefor worth the added complexity
they add to the yoctoproject git namespace and on the system administrator.

For #2, people need to be able to prepare a tree and poke someone in IRC
with a git URL to try out. Many of these are likely to be short lived,
and to only have a single contributor. As such, they are not worth
polluting the yoctoproject git namespace, nor should we burden our
system admin with setting them up and tearing them down. Indeed, they
are likely to linger, continuing to pollute the namespace long after
they are dead trees simply due to the overhead of removing them!

As for BSP's... these don't seem to have a lot of contributors - at
least from what I have seen. Typically 1 or 2 people. For that scenario,
I see two processes as options:

a) add user branches:
master
bernard
dvhart/topicA
dvhart/topicB
tzanussi/topicA
tzanussi/topicD
Yeah, that's what you and I do already. But we now have people coming
online who will be be continually pushing changes to their bsps in
meta-intel and we don't necessarily want to give them write access to
meta-intel itself right away, I assume...

b) use the personal repositories described in #2 above
Yeah, so we could create and manage meta-intel-contrib ourselves without
bothering any admins...

Tom

While it is possible to use poky-contrib for things like this, I think
it is non-intuitive to use a repository as a remote to a repository that
isn't based off the remote repository (like BSP layers which aren't part
of poky). For most users, this will result in pulling down MBs of
unnecessary git objects. Yes, you can use --reference when cloning. Yes,
you can use fancy fetch commands. No, nobody will.

Thanks,


Re: Personal git repositories

Darren Hart <dvhart@...>
 

On 04/26/2011 09:37 PM, Saul Wold wrote:
On 04/26/2011 08:57 PM, Darren Hart wrote:


On 04/26/2011 08:22 PM, Bruce Ashfield wrote:
On 11-04-26 11:00 PM, Darren Hart wrote:
git.yoctoproject.org hosts a number of different repositories, some of
which host limited user contributions (such as poky-contrib). These
repositories are setup and administered by a yoctoproject.org system admin.

As our developer base grows, the need for user creatable git trees also
grows. Eventually, *-contrib isn't going to scale, and neither will the
system admin. There are plenty of available places individuals can
create publicly accessible trees (github, kernel.org, or any number of
similar sites). However, I think it would be beneficial for at least
very active developers to be able to create and destroy trees on a whim,
without having to involve the system admin with each event.

kernel.org provides a git web interface for user created trees. I'd like
to see something similar available at yoctoproject.org in order to
establish single place to go looking for "yocto developer trees". Users
would have to justify their request for a user account and agree to a
terms of use. This has served the Linux kernel community very well. I
think it could do the same for us.

Note: I am not offering to setup such a service or even say that it's
possible with the current resources. I just wanted to throw the idea out
there and see if others have found a similar gap in the development
environment and if this idea would address that gap.

Thoughts?
Only a 2nd vote for something like this. I've had a need for
this on several occasions, and often I'd like to get something out, and
then slot it into a more "official" location later. My current
location for the 2.6.39-yocto kernel on my kernel.org account sort
of says it all :)
Right. I just pushed meta-boottime to my kernel.org account as well. I'd
much rather have that be:

git://git.yoctoproject.org/dvhart/meta-boottime.git

I also think this is a good idea, but can we wait until we get things
transitioned to the new server and stabilized before adding new things
right now?
I believe so. Bruce and I can use kernel.org for now. Tom and I can use
personal branches in meta-intel. But I'd like to see a solution here
before we see widespread use of kernel.org and github to manage git
trees as it will be collectively a lot more work to move people to the
new infrastructure - and we'll lose some mindshare in the meantime.

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


Re: Personal git repositories

Darren Hart <dvhart@...>
 

On 04/26/2011 09:39 PM, Tom Zanussi wrote:
On Tue, 2011-04-26 at 20:00 -0700, Darren Hart wrote:
git.yoctoproject.org hosts a number of different repositories, some of
which host limited user contributions (such as poky-contrib). These
repositories are setup and administered by a yoctoproject.org system admin.

As our developer base grows, the need for user creatable git trees also
grows. Eventually, *-contrib isn't going to scale, and neither will the
system admin. There are plenty of available places individuals can
create publicly accessible trees (github, kernel.org, or any number of
similar sites). However, I think it would be beneficial for at least
very active developers to be able to create and destroy trees on a whim,
without having to involve the system admin with each event.

kernel.org provides a git web interface for user created trees. I'd like
to see something similar available at yoctoproject.org in order to
establish single place to go looking for "yocto developer trees". Users
would have to justify their request for a user account and agree to a
terms of use. This has served the Linux kernel community very well. I
think it could do the same for us.

Note: I am not offering to setup such a service or even say that it's
possible with the current resources. I just wanted to throw the idea out
there and see if others have found a similar gap in the development
environment and if this idea would address that gap.

Thoughts?
My thinking (I guess - I didn't really think that much about it at the
time) when requesting the meta-intel-contrib repo was that repos that
could expect to get continual contributions from many people would
benefit from having a corresponding -contrib version - so far that's
poky-contrib, linux-yocto-*.contrib, and openembedded-core-contrib. To
me bsp repos fit the same criteria, but I'm not the one who has to
manage it all, so I understand the desire to avoid the proliferation.

Seems like the personal repos idea would mitigate the problem...
I think these are two distinct but overlapping problems:

1) place to share on the common core (poky, linux-yocto*)
2) place to share new stuff that may not amount to anything

For #1, the *-contrib git repositories make sense to me. It provides a
single repository that a lot of people use and reduces the git remote
management for everyone. They are therefor worth the added complexity
they add to the yoctoproject git namespace and on the system administrator.

For #2, people need to be able to prepare a tree and poke someone in IRC
with a git URL to try out. Many of these are likely to be short lived,
and to only have a single contributor. As such, they are not worth
polluting the yoctoproject git namespace, nor should we burden our
system admin with setting them up and tearing them down. Indeed, they
are likely to linger, continuing to pollute the namespace long after
they are dead trees simply due to the overhead of removing them!

As for BSP's... these don't seem to have a lot of contributors - at
least from what I have seen. Typically 1 or 2 people. For that scenario,
I see two processes as options:

a) add user branches:
master
bernard
dvhart/topicA
dvhart/topicB
tzanussi/topicA
tzanussi/topicD

b) use the personal repositories described in #2 above

While it is possible to use poky-contrib for things like this, I think
it is non-intuitive to use a repository as a remote to a repository that
isn't based off the remote repository (like BSP layers which aren't part
of poky). For most users, this will result in pulling down MBs of
unnecessary git objects. Yes, you can use --reference when cloning. Yes,
you can use fancy fetch commands. No, nobody will.

Thanks,

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


Re: Personal git repositories

Tom Zanussi <tom.zanussi@...>
 

On Tue, 2011-04-26 at 20:00 -0700, Darren Hart wrote:
git.yoctoproject.org hosts a number of different repositories, some of
which host limited user contributions (such as poky-contrib). These
repositories are setup and administered by a yoctoproject.org system admin.

As our developer base grows, the need for user creatable git trees also
grows. Eventually, *-contrib isn't going to scale, and neither will the
system admin. There are plenty of available places individuals can
create publicly accessible trees (github, kernel.org, or any number of
similar sites). However, I think it would be beneficial for at least
very active developers to be able to create and destroy trees on a whim,
without having to involve the system admin with each event.

kernel.org provides a git web interface for user created trees. I'd like
to see something similar available at yoctoproject.org in order to
establish single place to go looking for "yocto developer trees". Users
would have to justify their request for a user account and agree to a
terms of use. This has served the Linux kernel community very well. I
think it could do the same for us.

Note: I am not offering to setup such a service or even say that it's
possible with the current resources. I just wanted to throw the idea out
there and see if others have found a similar gap in the development
environment and if this idea would address that gap.

Thoughts?
My thinking (I guess - I didn't really think that much about it at the
time) when requesting the meta-intel-contrib repo was that repos that
could expect to get continual contributions from many people would
benefit from having a corresponding -contrib version - so far that's
poky-contrib, linux-yocto-*.contrib, and openembedded-core-contrib. To
me bsp repos fit the same criteria, but I'm not the one who has to
manage it all, so I understand the desire to avoid the proliferation.

Seems like the personal repos idea would mitigate the problem...

Tom