All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [RFC] Make some big but only formal change before next stable - SRCPV
Date: Tue, 9 Mar 2010 12:59:05 +0100	[thread overview]
Message-ID: <20100309115905.GM31945@jama> (raw)
In-Reply-To: <1268130988.14566.922.camel@mill.internal.reciva.com>

On Tue, Mar 09, 2010 at 10:36:28AM +0000, Phil Blundell wrote:
> On Tue, 2010-03-09 at 08:53 +0100, Martin Jansa wrote:
> > My SRCPV migration branch is quickly rotting.. but I'm willing to
> > check/do it again, because resolving conflicts with every small change
> > in git recipe takes me more time than merging SRCPV to oe.dev would
> > take.
> 
> At the risk of sounding like a terrible dimwit, I am still not entirely
> clear on why you can't just do something like

Feeling the same here now..

> PKGV = "0.0+git${@bb.fetch.get_srcrev(d)}.${PV}"

How this should work?

is PV at the end typo from PR or do you really mean that srcrev has higher
priority than PV?

> which seems like it would make this whole problem go away without
> needing any further changes to bitbake.

All changes are already there. What's new in master is optional support
for forcing that incrementing part to same value across builders, without
local cache synchronization.

And also caching for revs returned when using BB_GIT_CLONE_FOR_SRCREV,
which can improve performance instead of running "git rev-list | wc -l"
with every get_srcrev(d).

Regards,

-- 
uin:136542059                jid:Martin.Jansa@gmail.com
Jansa Martin                 sip:jamasip@voip.wengo.fr 
JaMa                         



  reply	other threads:[~2010-03-09 12:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-09  7:53 [RFC] Make some big but only formal change before next stable - SRCPV Martin Jansa
2010-03-09 10:36 ` Phil Blundell
2010-03-09 11:59   ` Martin Jansa [this message]
2010-03-09 16:33     ` Phil Blundell
2010-03-09 14:00 ` Koen Kooi
2010-03-09 20:41   ` Phil Blundell
2010-03-10  9:48     ` Sebastian Spaeth
2010-03-10 14:56       ` Koen Kooi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100309115905.GM31945@jama \
    --to=martin.jansa@gmail.com \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.