Re: [yocto] Personal git repositories
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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] qemu-system-mipsel
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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Personal git repositories
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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Personal git repositories
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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/1] Resend:[Image-Creator]Make bitbake server type configurable (xmlrpc, none)
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
>
> Add -t options in bitbake for configuring server type.
>
> Signed-off-by: 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
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/1] Resend:[Image-Creator]Make bitbake server type configurable (xmlrpc, none)
Hi, Josh Thanks for your very careful review indeed! I will correct them and resend the patch! Regards, criping > -Original Message- > From: Joshua Lock [mailto:j...@linux.intel.com] > Sent: Friday, April 29, 2011 4:32 AM > To: Ke, Liping > Cc: yocto@yoctoproject.org > Subject: Re: [yocto] [PATCH 1/1] Resend:[Image-Creator]Make bitbake server > type configurable (xmlrpc, none) > > 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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/1] Resend:[Image-Creator]Make bitbake server type configurable (xmlrpc, none)
From: Liping Ke Add -t options in bitbake for configuring server type. Signed-off-by: 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 (1): Make bitbake server type configurable(xmlrpc,none) bitbake/bin/bitbake | 22 +- 1 files changed, 17 insertions(+), 5 deletions(-) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/1] Resend:[Image-Creator]Make bitbake server type configurable(xmlrpc, none)
From: Liping Ke
Add -t options in bitbake for configuring server type.
Signed-off-by: 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
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Personal git repositories
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://g...@git.pokylinux.org/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 >> /*. 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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
