Pull request with misc changes

Pull request with misc changes

[Otavio Salvador]

Hello,

This pull request fixes some issues I found since the last pull
request and should be preferred against the first.

The following changes since commit d0dc2b5bb02ef55a41e7a97b6831c72391ae7f36:

  u-boot: correct COPYING MD5SUM (2011-05-08 23:56:11 -0700)

are available in the git repository at:
  git://github.com/OSSystems/oe-core master

Otavio Salvador (10):
      meta/conf/local.conf.sample: fix mklibs comment line split and typo
      scripts/oe-setup-builddir: fix typo
      syslinux: improve packaging
      busybox: add support to mdev
      libxkbfile: disable xcb
      insane.bbclass: skip license checksum if LICENSE is "CLOSED"
      cmake.bbclass: fix qmake and rpath issues
      qmake_base.bbclass: add generate_qt_config_file task
      cmake: add support for oe qt4 tools names
      fuse: drop since it is not used by other recipes

 .../fuse-2.7.2/not-run-updaterc.d-on-host.patch    |   15 ----
 meta-demoapps/recipes-kernel/fuse/fuse.inc         |   13 ---
 meta-demoapps/recipes-kernel/fuse/fuse_2.7.2.bb    |   22 -----
 meta/classes/cmake.bbclass                         |   19 ++++-
 meta/classes/insane.bbclass                        |    4 +
 meta/classes/qmake_base.bbclass                    |   15 ++++
 meta/conf/local.conf.sample                        |    7 +-
 meta/recipes-core/busybox/busybox.inc              |   14 +++-
 meta/recipes-core/busybox/busybox_1.18.4.bb        |    2 +
 meta/recipes-core/busybox/files/mdev               |    7 ++
 meta/recipes-core/busybox/files/mdev.conf          |   35 ++++++++
 meta/recipes-devtools/cmake/cmake-native_2.8.3.bb  |    2 +-
 meta/recipes-devtools/cmake/cmake.inc              |    3 +-
 .../cmake/cmake/support-oe-qt4-tools-names.patch   |   85 ++++++++++++++++++++
 meta/recipes-devtools/syslinux/syslinux_4.03.bb    |   12 +++-
 meta/recipes-graphics/xorg-lib/libxkbfile_1.0.7.bb |    4 +-
 scripts/oe-setup-builddir                          |    2 +-
 17 files changed, 199 insertions(+), 62 deletions(-)
 delete mode 100644
meta-demoapps/recipes-kernel/fuse/fuse-2.7.2/not-run-updaterc.d-on-host.patch
 delete mode 100644 meta-demoapps/recipes-kernel/fuse/fuse.inc
 delete mode 100644 meta-demoapps/recipes-kernel/fuse/fuse_2.7.2.bb
 create mode 100755 meta/recipes-core/busybox/files/mdev
 create mode 100644 meta/recipes-core/busybox/files/mdev.conf
 create mode 100644
meta/recipes-devtools/cmake/cmake/support-oe-qt4-tools-names.patch


-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Pull request with misc changes

[Saul Wold]

On 05/09/2011 12:15 PM, Otavio Salvador wrote:
> Hello,
>
> This pull request fixes some issues I found since the last pull
> request and should be preferred against the first.
>
Otavio,

Next time, please use the create-pull-request script, which will 
generate a set of patch emails so that we can review this information 
via email. I will make a couple of additional comments below associated 
with each patch.

> The following changes since commit d0dc2b5bb02ef55a41e7a97b6831c72391ae7f36:
>
>    u-boot: correct COPYING MD5SUM (2011-05-08 23:56:11 -0700)
>
> are available in the git repository at:
>    git://github.com/OSSystems/oe-core master
>
> Otavio Salvador (10):
>        meta/conf/local.conf.sample: fix mklibs comment line split and typo
>        scripts/oe-setup-builddir: fix typo
>        syslinux: improve packaging
>        busybox: add support to mdev
>        libxkbfile: disable xcb
>        insane.bbclass: skip license checksum if LICENSE is "CLOSED"
I assume you are adding this for layers and commercial work, we should 
never have CLOSED in any open layer.

>        cmake.bbclass: fix qmake and rpath issues
>        qmake_base.bbclass: add generate_qt_config_file task
>        cmake: add support for oe qt4 tools names
Please add a comment to the patch explaining it's purpose and origin, 
and include a Signed-off-by: if appropriate. Any patches that you have 
modified or added should include the above info.

>        fuse: drop since it is not used by other recipes
>
>   .../fuse-2.7.2/not-run-updaterc.d-on-host.patch    |   15 ----
>   meta-demoapps/recipes-kernel/fuse/fuse.inc         |   13 ---
>   meta-demoapps/recipes-kernel/fuse/fuse_2.7.2.bb    |   22 -----
>   meta/classes/cmake.bbclass                         |   19 ++++-
>   meta/classes/insane.bbclass                        |    4 +
>   meta/classes/qmake_base.bbclass                    |   15 ++++
>   meta/conf/local.conf.sample                        |    7 +-
>   meta/recipes-core/busybox/busybox.inc              |   14 +++-
>   meta/recipes-core/busybox/busybox_1.18.4.bb        |    2 +
>   meta/recipes-core/busybox/files/mdev               |    7 ++
>   meta/recipes-core/busybox/files/mdev.conf          |   35 ++++++++
>   meta/recipes-devtools/cmake/cmake-native_2.8.3.bb  |    2 +-
>   meta/recipes-devtools/cmake/cmake.inc              |    3 +-
>   .../cmake/cmake/support-oe-qt4-tools-names.patch   |   85 ++++++++++++++++++++
>   meta/recipes-devtools/syslinux/syslinux_4.03.bb    |   12 +++-
>   meta/recipes-graphics/xorg-lib/libxkbfile_1.0.7.bb |    4 +-
>   scripts/oe-setup-builddir                          |    2 +-
>   17 files changed, 199 insertions(+), 62 deletions(-)
>   delete mode 100644
> meta-demoapps/recipes-kernel/fuse/fuse-2.7.2/not-run-updaterc.d-on-host.patch
>   delete mode 100644 meta-demoapps/recipes-kernel/fuse/fuse.inc
>   delete mode 100644 meta-demoapps/recipes-kernel/fuse/fuse_2.7.2.bb
>   create mode 100755 meta/recipes-core/busybox/files/mdev
>   create mode 100644 meta/recipes-core/busybox/files/mdev.conf
>   create mode 100644
> meta/recipes-devtools/cmake/cmake/support-oe-qt4-tools-names.patch
>
>

Re: Pull request with misc changes

[Otavio Salvador]

On Tue, May 10, 2011 at 02:17, Saul Wold <sgw@linux.intel.com> wrote:
> Next time, please use the create-pull-request script, which will generate a
> set of patch emails so that we can review this information via email. I will
> make a couple of additional comments below associated with each patch.

It has a problem to me since it depends on using the contrib repo and
I am using github.
...
>>       insane.bbclass: skip license checksum if LICENSE is "CLOSED"
>
> I assume you are adding this for layers and commercial work, we should never
> have CLOSED in any open layer.

Sure. I fully agree but I also think it is insane to have to provide a
fake license file to workaround it in every repository I am using
internally.

>>       cmake: add support for oe qt4 tools names
>
> Please add a comment to the patch explaining it's purpose and origin, and
> include a Signed-off-by: if appropriate. Any patches that you have modified
> or added should include the above info.

On the patch itself? Any doc describing an example of it?

I am waiting for Richard and Koen replies about my questions and will
provide updated patches for the unmerged ones.

Cheers,

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Pull request with misc changes

[Saul Wold]

On 05/10/2011 05:53 AM, Otavio Salvador wrote:
> On Tue, May 10, 2011 at 02:17, Saul Wold<sgw@linux.intel.com>  wrote:
>> Next time, please use the create-pull-request script, which will generate a
>> set of patch emails so that we can review this information via email. I will
>> make a couple of additional comments below associated with each patch.
>
> It has a problem to me since it depends on using the contrib repo and
> I am using github.
> ...
Is there a reason you can't use the oe-core-contrib repo and create a 
branch there?  Can the script be modified to support github also?

It creates get another remote that we need to fetch from.

>>>        insane.bbclass: skip license checksum if LICENSE is "CLOSED"
>>
>> I assume you are adding this for layers and commercial work, we should never
>> have CLOSED in any open layer.
>
> Sure. I fully agree but I also think it is insane to have to provide a
> fake license file to workaround it in every repository I am using
> internally.
>
We agree, thanks for this change.

>>>        cmake: add support for oe qt4 tools names
>>
>> Please add a comment to the patch explaining it's purpose and origin, and
>> include a Signed-off-by: if appropriate. Any patches that you have modified
>> or added should include the above info.
>
> On the patch itself? Any doc describing an example of it?
>
Mark Hatle has (or will have shortly) a proposal out to the OE community 
for commit and patch message guidelines, as a starting point, you can 
look at the wiki:

https://wiki.yoctoproject.org/wiki/Recipe_%26_Patch_Style_Guide

This will be updated in the next 24 hours or so.

Sau!

> I am waiting for Richard and Koen replies about my questions and will
> provide updated patches for the unmerged ones.
>
> Cheers,
>

Re: Pull request with misc changes

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1881 bytes --]

On Tue, May 10, 2011 at 11:00:07AM -0700, Saul Wold wrote:
> On 05/10/2011 05:53 AM, Otavio Salvador wrote:
> > On Tue, May 10, 2011 at 02:17, Saul Wold<sgw@linux.intel.com>  wrote:
> >> Next time, please use the create-pull-request script, which will generate a
> >> set of patch emails so that we can review this information via email. I will
> >> make a couple of additional comments below associated with each patch.
> >
> > It has a problem to me since it depends on using the contrib repo and
> > I am using github.
> > ...
> Is there a reason you can't use the oe-core-contrib repo and create a 
> branch there?  Can the script be modified to support github also?

I'm using slightly modified script for pull requests from gitorious.

send-pull-request are the same as long as you use git send-email and
have sendemail.to defined in repo.

To modify it for github is as simple as this I guess.

$ diff -uNr shr-core/openembedded-core/scripts/create-pull-request ~/bin/meta-efl-create-pull-request 
--- shr-core/openembedded-core/scripts/create-pull-request 2011-04-04 09:35:47.973626385 +0200
+++ /OE/bin/meta-efl-create-pull-request        2011-05-10 13:33:20.349688815 +0200
@@ -2,9 +2,11 @@
 ODIR=pull-$$
 RELATIVE_TO="master"
 COMMIT_ID="HEAD"
-PULL_URL="git://git.openembedded.org/openembedded-core-contrib"
-WEB_URL_PREFIX="http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h="
-PREFIX="PATCH"
+#PULL_URL="git://git.openembedded.org/meta-openembedded-contrib"
+#WEB_URL_PREFIX="http://git.openembedded.org/cgit.cgi/meta-openembedded-contrib/log/?h="
+PULL_URL="git://gitorious.org/shr/meta-openembedded.git"
+WEB_URL_PREFIX="http://gitorious.org/shr/meta-openembedded/commits/"
+PREFIX="meta-efl][PATCH"
 
 usage() {
 CMD=$(basename $0)

Regards,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

Re: Pull request with misc changes

[Otavio Salvador]

On Tue, May 10, 2011 at 15:00, Saul Wold <sgw@linux.intel.com> wrote:
> Is there a reason you can't use the oe-core-contrib repo and create a branch
> there?  Can the script be modified to support github also?

Not a hard one but I prefer to have it into our repository since
people can fork it there and follow it.

> It creates get another remote that we need to fetch from.

Or it creates another remote I need to push to.

To merge you don't need to add a remote but pull from the git URL
included into the pull command line.

...
>> On the patch itself? Any doc describing an example of it?
>>
> Mark Hatle has (or will have shortly) a proposal out to the OE community for
> commit and patch message guidelines, as a starting point, you can look at
> the wiki:
>
> https://wiki.yoctoproject.org/wiki/Recipe_%26_Patch_Style_Guide

I have pushed it already. It is available on the mailing list, please
take a look.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Pull request with misc changes

[Tom Rini]

On 05/10/2011 11:13 AM, Martin Jansa wrote:
> On Tue, May 10, 2011 at 11:00:07AM -0700, Saul Wold wrote:
>> On 05/10/2011 05:53 AM, Otavio Salvador wrote:
>>> On Tue, May 10, 2011 at 02:17, Saul Wold<sgw@linux.intel.com>  wrote:
>>>> Next time, please use the create-pull-request script, which will generate a
>>>> set of patch emails so that we can review this information via email. I will
>>>> make a couple of additional comments below associated with each patch.
>>>
>>> It has a problem to me since it depends on using the contrib repo and
>>> I am using github.
>>> ...
>> Is there a reason you can't use the oe-core-contrib repo and create a 
>> branch there?  Can the script be modified to support github also?
> 
> I'm using slightly modified script for pull requests from gitorious.
> 
> send-pull-request are the same as long as you use git send-email and
> have sendemail.to defined in repo.
> 
> To modify it for github is as simple as this I guess.
> 
> $ diff -uNr shr-core/openembedded-core/scripts/create-pull-request ~/bin/meta-efl-create-pull-request 
> --- shr-core/openembedded-core/scripts/create-pull-request 2011-04-04 09:35:47.973626385 +0200
> +++ /OE/bin/meta-efl-create-pull-request        2011-05-10 13:33:20.349688815 +0200
> @@ -2,9 +2,11 @@
>  ODIR=pull-$$
>  RELATIVE_TO="master"
>  COMMIT_ID="HEAD"
> -PULL_URL="git://git.openembedded.org/openembedded-core-contrib"
> -WEB_URL_PREFIX="http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h="
> -PREFIX="PATCH"
> +#PULL_URL="git://git.openembedded.org/meta-openembedded-contrib"
> +#WEB_URL_PREFIX="http://git.openembedded.org/cgit.cgi/meta-openembedded-contrib/log/?h="
> +PULL_URL="git://gitorious.org/shr/meta-openembedded.git"
> +WEB_URL_PREFIX="http://gitorious.org/shr/meta-openembedded/commits/"
> +PREFIX="meta-efl][PATCH"
>  
>  usage() {
>  CMD=$(basename $0)

Hmmm.  I'm going to take a stab at making this a create-pull-request
option...

-- 
Tom Rini
Mentor Graphics Corporation

Re: Pull request with misc changes

[Richard Purdie]

On Tue, 2011-05-10 at 11:33 -0700, Tom Rini wrote:
> On 05/10/2011 11:13 AM, Martin Jansa wrote:
> > I'm using slightly modified script for pull requests from gitorious.
> > 
> > send-pull-request are the same as long as you use git send-email and
> > have sendemail.to defined in repo.
> > 
> > To modify it for github is as simple as this I guess.
> > 
> > $ diff -uNr shr-core/openembedded-core/scripts/create-pull-request ~/bin/meta-efl-create-pull-request 
> > --- shr-core/openembedded-core/scripts/create-pull-request 2011-04-04 09:35:47.973626385 +0200
> > +++ /OE/bin/meta-efl-create-pull-request        2011-05-10 13:33:20.349688815 +0200
> > @@ -2,9 +2,11 @@
> >  ODIR=pull-$$
> >  RELATIVE_TO="master"
> >  COMMIT_ID="HEAD"
> > -PULL_URL="git://git.openembedded.org/openembedded-core-contrib"
> > -WEB_URL_PREFIX="http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h="
> > -PREFIX="PATCH"
> > +#PULL_URL="git://git.openembedded.org/meta-openembedded-contrib"
> > +#WEB_URL_PREFIX="http://git.openembedded.org/cgit.cgi/meta-openembedded-contrib/log/?h="
> > +PULL_URL="git://gitorious.org/shr/meta-openembedded.git"
> > +WEB_URL_PREFIX="http://gitorious.org/shr/meta-openembedded/commits/"
> > +PREFIX="meta-efl][PATCH"
> >  
> >  usage() {
> >  CMD=$(basename $0)
> 
> Hmmm.  I'm going to take a stab at making this a create-pull-request
> option...

Martin/Tom: Serious question - why not use the contrib repo for this?

I have nightmares about all the development being spread to all the
corners of the globe and people not being able to see what is being
worked on. For short lived branches its not so much of a problem but as
we take on longer lived feature development it will be a problem. I'd
therefore like to understand why the dislike of it...

Cheers,

Richard

Re: Pull request with misc changes

[Otavio Salvador]

On Tue, May 10, 2011 at 16:03, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>> Hmmm.  I'm going to take a stab at making this a create-pull-request
>> option...
>
> Martin/Tom: Serious question - why not use the contrib repo for this?
>
> I have nightmares about all the development being spread to all the
> corners of the globe and people not being able to see what is being
> worked on. For short lived branches its not so much of a problem but as
> we take on longer lived feature development it will be a problem. I'd
> therefore like to understand why the dislike of it...

Welcome to Distribute Source Control Management World; this is the
beauty of it and I see no reason to restrict or enforce people to use
a repository.

In my personal case we have been using GitHub as a central place to
put projects that O.S. Systems is contributing and this is good to
gather us some visibility so OE will be there too.

So I won't use contrib to share patches. I can send them to mailing
list (as I have been doing). A merge on a topic branch is a git pull
command from you so I see not much problem for you or whom is doing
the pull job.

As an example:

 git checkout -b otavio-20110510-review
 git pull git://github.com/OSSystems/oe-core.git master
 git shortlog origin/master..

Is that so difficult?


-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Pull request with misc changes

[Richard Purdie]

On Tue, 2011-05-10 at 16:15 -0300, Otavio Salvador wrote:
> On Tue, May 10, 2011 at 16:03, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> >> Hmmm.  I'm going to take a stab at making this a create-pull-request
> >> option...
> >
> > Martin/Tom: Serious question - why not use the contrib repo for this?
> >
> > I have nightmares about all the development being spread to all the
> > corners of the globe and people not being able to see what is being
> > worked on. For short lived branches its not so much of a problem but as
> > we take on longer lived feature development it will be a problem. I'd
> > therefore like to understand why the dislike of it...
> 
> Welcome to Distribute Source Control Management World; this is the
> beauty of it and I see no reason to restrict or enforce people to use
> a repository.

Nobody wants to force anyone. I just asked for the reasons why people
weren't using it as if there was anything we could fix, we could look
into it.

> In my personal case we have been using GitHub as a central place to
> put projects that O.S. Systems is contributing and this is good to
> gather us some visibility so OE will be there too.
> 
> So I won't use contrib to share patches. I can send them to mailing
> list (as I have been doing). A merge on a topic branch is a git pull
> command from you so I see not much problem for you or whom is doing
> the pull job.
> 
> As an example:
> 
>  git checkout -b otavio-20110510-review
>  git pull git://github.com/OSSystems/oe-core.git master
>  git shortlog origin/master..
> 
> Is that so difficult?

I didn't say it was difficult ;-).

Thanks for answering the question, there is little we can do to change
your reasons for what you do and that's fine. I've ensured we're not
doing something that forces you elsewhere at least.

Cheers,

Richard

Re: Pull request with misc changes

[Chris Larson]

On Tue, May 10, 2011 at 12:15 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Tue, May 10, 2011 at 16:03, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>>> Hmmm.  I'm going to take a stab at making this a create-pull-request
>>> option...
>>
>> Martin/Tom: Serious question - why not use the contrib repo for this?
>>
>> I have nightmares about all the development being spread to all the
>> corners of the globe and people not being able to see what is being
>> worked on. For short lived branches its not so much of a problem but as
>> we take on longer lived feature development it will be a problem. I'd
>> therefore like to understand why the dislike of it...
>
> Welcome to Distribute Source Control Management World; this is the
> beauty of it and I see no reason to restrict or enforce people to use
> a repository.
>
> In my personal case we have been using GitHub as a central place to
> put projects that O.S. Systems is contributing and this is good to
> gather us some visibility so OE will be there too.
>
> So I won't use contrib to share patches. I can send them to mailing
> list (as I have been doing). A merge on a topic branch is a git pull
> command from you so I see not much problem for you or whom is doing
> the pull job.
>
> As an example:
>
>  git checkout -b otavio-20110510-review
>  git pull git://github.com/OSSystems/oe-core.git master
>  git shortlog origin/master..
>

Even easier, one command to get it into a local branch:

git fetch git://github.com/OSSystems/oe-core.git master:otavio-20110510-review
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: Pull request with misc changes

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 959 bytes --]

On Tue, May 10, 2011 at 08:03:57PM +0100, Richard Purdie wrote:
> Martin/Tom: Serious question - why not use the contrib repo for this?

I have nothing against contrib repo and I'm using oe-core-contrib for
oe-core stuff, but I had gitorious repos for meta-oe before
meta-oe-contrib was created and now I didn't feel the need to change it
and update my modified meta-oe-create-pull-request header :) but I will
if you or koen find it better to pull from *-contrib (I'm pushing shr
branch there already anyways).

> I have nightmares about all the development being spread to all the
> corners of the globe and people not being able to see what is being
> worked on. For short lived branches its not so much of a problem but as
> we take on longer lived feature development it will be a problem. I'd
> therefore like to understand why the dislike of it...
> 
> Cheers,

Cheers,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

Re: Pull request with misc changes

[Koen Kooi]

Op 10 mei 2011, om 22:24 heeft Martin Jansa het volgende geschreven:

> On Tue, May 10, 2011 at 08:03:57PM +0100, Richard Purdie wrote:
>> Martin/Tom: Serious question - why not use the contrib repo for this?
> 
> I have nothing against contrib repo and I'm using oe-core-contrib for
> oe-core stuff, but I had gitorious repos for meta-oe before
> meta-oe-contrib was created and now I didn't feel the need to change it
> and update my modified meta-oe-create-pull-request header :) but I will
> if you or koen find it better to pull from *-contrib (I'm pushing shr
> branch there already anyways).


I have no preference either way.

regards,

Koen

Re: Pull request with misc changes

[Darren Hart]

On 05/10/2011 11:20 AM, Otavio Salvador wrote:
> On Tue, May 10, 2011 at 15:00, Saul Wold <sgw@linux.intel.com> wrote:
>> Is there a reason you can't use the oe-core-contrib repo and create a branch
>> there?  Can the script be modified to support github also?
> 
> Not a hard one but I prefer to have it into our repository since
> people can fork it there and follow it.

I use the script for multiple repositories (poky, oe-core, meta-intel,
and various other layers). A configurable remote URL would be a
reasonable thing to add to the script. Perhaps leveraging something from
the current .git/config ? I haven't really looked into it, but if
someone else wants to I am not opposed to discussing it.

--
Darren

> 
>> It creates get another remote that we need to fetch from.
> 
> Or it creates another remote I need to push to.
> 
> To merge you don't need to add a remote but pull from the git URL
> included into the pull command line.
> 
> ...
>>> On the patch itself? Any doc describing an example of it?
>>>
>> Mark Hatle has (or will have shortly) a proposal out to the OE community for
>> commit and patch message guidelines, as a starting point, you can look at
>> the wiki:
>>
>> https://wiki.yoctoproject.org/wiki/Recipe_%26_Patch_Style_Guide
> 
> I have pushed it already. It is available on the mailing list, please
> take a look.
> 

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

Re: Pull request with misc changes

[Richard Purdie]

On Tue, 2011-05-10 at 22:24 +0200, Martin Jansa wrote:
> On Tue, May 10, 2011 at 08:03:57PM +0100, Richard Purdie wrote:
> > Martin/Tom: Serious question - why not use the contrib repo for this?
> 
> I have nothing against contrib repo and I'm using oe-core-contrib for
> oe-core stuff, but I had gitorious repos for meta-oe before
> meta-oe-contrib was created and now I didn't feel the need to change it
> and update my modified meta-oe-create-pull-request header :) but I will
> if you or koen find it better to pull from *-contrib (I'm pushing shr
> branch there already anyways).

I have a habit of using the cgit web interface to visualise patches so
using the contrib repo does help me a little. As you say, you're using
oe-core-contrib though so thats fine :)

FWIW, I find the gitorious web interface extremely painful to the point
of being unusable to get the information I want from it. Could just be
me but I have to pull trees somewhere else to look at them I find it
that painful.

Cheers,

Richard

Re: Pull request with misc changes

[Koen Kooi]

Op 11 mei 2011, om 11:17 heeft Richard Purdie het volgende geschreven:

> On Tue, 2011-05-10 at 22:24 +0200, Martin Jansa wrote:
>> On Tue, May 10, 2011 at 08:03:57PM +0100, Richard Purdie wrote:
>>> Martin/Tom: Serious question - why not use the contrib repo for this?
>> 
>> I have nothing against contrib repo and I'm using oe-core-contrib for
>> oe-core stuff, but I had gitorious repos for meta-oe before
>> meta-oe-contrib was created and now I didn't feel the need to change it
>> and update my modified meta-oe-create-pull-request header :) but I will
>> if you or koen find it better to pull from *-contrib (I'm pushing shr
>> branch there already anyways).
> 
> I have a habit of using the cgit web interface to visualise patches so
> using the contrib repo does help me a little. As you say, you're using
> oe-core-contrib though so thats fine :)
> 
> FWIW, I find the gitorious web interface extremely painful to the point
> of being unusable to get the information I want from it. Could just be
> me but I have to pull trees somewhere else to look at them I find it
> that painful.

The github one is a lot better, you can even add inline comments using the gui.