Re: [yocto] Personal git repositories
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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [RFC] fix seg fault of evolution-data-server when adding default vcard
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
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.0 +0800
+++
evolution-data-server/addressbook/backends/file/e-book-backend-file.c
2011-04-26 15:59:13.0 +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/
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Personal git repositories
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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Personal git repositories
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://g...@git.pokylinux.org/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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Personal git repositories
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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Personal git repositories
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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Personal git repositories
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://g...@git.pokylinux.org/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 /*. 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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Personal git repositories
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 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
Re: [yocto] Personal git repositories
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://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 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 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@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Schedule at-a-glance now on schedule wiki
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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Personal git repositories
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 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://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 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 > > 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@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > ___ 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] (no subject)
From: 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
---
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
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
