All of lore.kernel.org
 help / color / mirror / Atom feed
From: pieterg <pieterg@gmx.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: AUTOREV and SRCPV
Date: Thu, 3 Jun 2010 10:02:31 +0200	[thread overview]
Message-ID: <201006031002.31685.pieterg@gmx.com> (raw)
In-Reply-To: <20100603073717.GK16035@jama>

On Thursday 03 June 2010 09:37:17 Martin Jansa wrote:
> On Thu, Jun 03, 2010 at 09:15:56AM +0200, pieterg wrote:
> > On Thursday 03 June 2010 06:35:05 Martin Jansa wrote:

<snip>

> > > If you use bitbake-1.10 it will do it just once for git revision (it
> > > will cache the result of "git list-rev | wc -l" which is used by
> > > BB_GIT_CLONE_FOR_SRCREV.
> >
> > Probably, but I don't get that far, bitbake quits at the end, with
> > several parsing errors (problems with git repositories which I have no
> > control over, and which I don't even want anything to do with)
>
> I'm aware of this problem and was discussed in that thread half a year
> ago, pity that you didn't join the discussion back then :/. But FYI all
> recipes with SRCPV builds OK here (without BB_GIT_CLONE_FOR_SRCREV but
> git servers are accessible for me).

Yes, I know I'm too late now ;)
We were way behind with our oe merges back then, and only recently I started 
to get back uptodate again. So I didn't even realise the impact it would 
have for us untill now.

> > There are two sorts of people, those with BB_GIT_CLONE_FOR_SRCREV, and
> > those without.
> > (or in my case, this is controlled by the distro, an 'unstable',
> > or 'release').
> > As long as the versioning is consistent for each group of people (or in
> > my case, each distro), I don't need the versioning to stay consistent
> > when toggling BB_GIT_CLONE_FOR_SRCREV.
>
> What about toggling AUTOREV and fixed revision? Which is imho more
> common change (ie when development gets slower and there is stable
> version in git and you don't need/want it AUTOREV). That's exacly the
> case when SRCPV is really handy.

But if you then decide to remove BB_GIT_CLONE_FOR_SRCREV again because you 
no longer need it, and somebody starts a clean build, the LOCALCOUNT would 
start at 0 again I guess.
So the versioning isn't consistent anyway when toggling 
BB_GIT_CLONE_FOR_SRCREV.

> The other is when you change SRCREV in recipe without updating PV. Then
> SRCPV will give you newer PV which will upgrade resulting package on
> target.

Yes, but only if you stick to the same buildserver, and as soon as the hdd 
crashes for instance and you have to start with a clean build, everybody is 
in trouble.
So personally, I would never even want to use SRCPV, unless it's for 
AUTOREV.

Would it be an idea to be able to only have BB_GIT_CLONE_FOR_SRCREV for 
those packages which have SRCREV = ${AUTOREV}?

Rgds, Pieter



  reply	other threads:[~2010-06-03  8:07 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-02 21:51 AUTOREV and SRCPV pieterg
2010-06-03  4:35 ` Martin Jansa
2010-06-03  7:15   ` pieterg
2010-06-03  7:37     ` Martin Jansa
2010-06-03  8:02       ` pieterg [this message]
2010-06-03  8:27         ` Martin Jansa
2010-06-03  8:44           ` pieterg
2010-06-03  9:22           ` pieterg
2010-06-03  8:13       ` Phil Blundell
2010-06-03  8:30         ` Martin Jansa
2010-06-03  8:37           ` Phil Blundell
2010-06-03  8:46             ` Martin Jansa
2010-06-03  8:55               ` Phil Blundell
2010-06-03 16:35                 ` Phil Blundell
2010-06-04  8:24                   ` pieterg
2010-06-04  8:30                     ` Phil Blundell
2010-06-04  8:44                       ` pieterg
2010-06-04 11:03                         ` Phil Blundell
2010-06-05 10:36                           ` pieterg
2010-06-06 21:00                             ` Phil Blundell
2010-06-07  0:13                               ` Khem Raj
2010-06-08 10:09                               ` Phil Blundell

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=201006031002.31685.pieterg@gmx.com \
    --to=pieterg@gmx.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.