Hi all,

As part of the 1.1 feature list I suggested a review of the
INCOMPATIBLE_LICENSE and COMMERCIAL* package exclusion mechanisms we have
within Poky. Below I've outlined my ideas and would appreciate any
comments/additions/corrections.

==== Aims ====

* Make error messages clear when user/dependencies have asked for something
to be built that can't be due to restrictions

* Ensure that exclusion system is reliable

==== Proposed implementation ====

1) Ensure all documentation of LICENSE field value syntax is clear, concise
and up-to-date (wiki and manual)

2) Go through and audit all recipes LICENSE field values to ensure that they
all conform to the specifications. This includes making sure that | (package
may be used under one of a selection of licences) and & (recipe has mixed
licences that apply to the code base, so conditions of all must be observed)
are used correctly.

3) bitbake/core changes:

* LICENSE field checking must fully parse the field and understand the
difference between | and &, and must not e.g. mark Qt as being GPLv3 only.

* Make the LICENSE validity checking more strict (given recipes have been
audited and rules are clear after above)

* Don't exclude any recipes at parse time - simply record all excluded
recipes and their runtime provides in a blacklist which also includes flags
indicating the reason for blacklisting

* Ensure all excluded licences in INCOMPATIBLE_LICENSE are valid (e.g. catch
GPL3 as apposed to GPLv3) - if not, error out

* Check when calculating dependencies if anything is scheduled to be built
that is on the blacklist - if any are, gather all of them up and then stop and
list them in an error message along with reason and depchain for each one

* Check when constructing the rootfs if anything in the runtime provides
blacklist is going to be included - if so, error out


Some further possible extensions:

* Possibly apply similar logic to COMPATIBLE_MACHINE?

* Replace COMMERCIAL* with some more generic exclusion mechanism that allows
the reason to be defined as part of the exclusion list?

* As a helper for non-en_US users, fail on parse if user defines any of the
*LICENSE* variables as *LICENCE*? (we definitely don't want the build to
continue and just ignore this as the user might not realise what has happened)


Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

On Fri, 2011-04-29 at 08:22 +0800, Liping Ke wrote:

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

Add -t options in bitbake for configuring server type.

Thanks Liping, this looks good to me. I've merged it into an
image-creator branch on contrib


I will be collecting image-creator related BitBake patches there for now
with the goal of porting them to upstream BitBake and submitting to the
bitbake-devel list (thought I haven't seen any traffic there for some
time)...

Cheers,
Joshua

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(-)

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

--
Joshua Lock
Yocto Build System Monkey
Intel Open Source Technology Center

Yocto Technical Team,
We will be having our regular Technical Team meeting on Tuesday at 8am. If you'd like to join, dial in and agenda are below.
Thanks.
- Julie

Dial in:
Tuesday, May 03, 2011, 08:00 AM US Pacific Time
916-356-2663, 8-356-2663, Bridge: 1, Passcode: 7982611

Agenda:
1. Review 1.1 Release Criteria - https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.1_Release_Criteria
2. Review 1.0.1 Release Criteria - https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.1_Release_Criteria#Yocto_Project_1.0.1
3. Opens



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

On 04/27/2011 03: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 just realized another major issue I have with this approach. It
doesn't just mean that I _can_ use git fetch to get a specific branch to
avoid pulling in a massive pile of objects I don't need, it means I have
to stop using "git remote update" entirely for everything else I do in
that repository and I have to fetch all the other branches manually. The
recommended approach here is VIRAL.

--
Darren

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

Hi, Josh

Thanks for your very careful review indeed! I will correct them and resend the patch!

Regards,
criping

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

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..b898f63 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: none [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

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(-)

Hi Liping,

This looks good to me. Two minor typo nits below, once they're fixed I
will create a branch on poky-contrib to collect image-creator related
patches until we're ready to switch to developing against upstream
bitbake.

Thanks,
Joshua


On Thu, 2011-04-28 at 13:38 +0800, Liping Ke wrote:

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

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

Can you capitalise choose please?

+ 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)

+ "Valid interfaces: xmlrpc, none [default]." %
servertype)

xmlrpc isn't the default, none is :-)

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

--
Joshua Lock
Yocto Build System Monkey
Intel Open Source Technology Center

On 04/28/2011 01:28 AM, Richard Purdie wrote:

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.

Agreed.

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)?

I don't know what gitolite is capable of. I would really like to be able
to create and destroy my own repositories in a central location with
other Yocto developers.

However, this doesn't block me from moving forward. I can use kernel.org
or dvhart.com to do this for the time being and make requests of the
admins when I have a repository that looks to have some staying power.
I'll have to time this transition appropriately so that I don't have to
ask too many people to migrate to the new URL, but that would be true of
a personal repository to official repository move as well.

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

On 11-04-28 04:28 AM, Richard Purdie wrote:

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.

Agreed with the points above. git really is just wrangling a bunch
of objects into commit chains and a branch points to a starting
point. So I completely agree that all chains don't have to lead to
the same origin, like you said, it is just how people tend to think.

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

I think we are likely ok, people have solutions that work, getting
the right contrib repos setup with appropriate permissions to setup
branches will go a long way.

As long as things stay responsive, I'd imagine that we'll find
that people will be happy with things as they are. At least we've
considered the options before it is critical.

Cheers,

Bruce

we can work within the existing system (or even extend gitolite)?

Cheers,

Richard

Hi,

Can someone please tell me what needs to be done to build
qemu-system-mipsel or provide a patch for it?

openembedded seems to be able to build something like this, so maybe it
would not be too difficult to cook some of the files from oe for yocto-poky.

Please advise,

Robert..."The IQ of the group is the lowest IQ of a member of the group
divided by the number of people in the group." - unknown

My public pgp key is available at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1

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

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

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(-)

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

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

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?

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

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

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