All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: Steffen Sledz <sledz@dresearch-fe.de>
Cc: openembedded-devel@lists.openembedded.org,
	openembedded-core@lists.openembedded.org
Subject: Re: [oe] SRC_URI and latest HEAD revision with git (in oe-classic)
Date: Wed, 31 Jul 2013 13:50:56 +0100	[thread overview]
Message-ID: <8337615.XrjW46moIm@helios> (raw)
In-Reply-To: <51F8E0C2.3070102@dresearch-fe.de>

On Wednesday 31 July 2013 12:02:42 Steffen Sledz wrote:
> On 22.07.2013 11:51, Paul Eggleton wrote:
> > On Monday 22 July 2013 11:46:23 Steffen Sledz wrote:
> >> On 22.07.2013 11:01, Nicolas Dechesne wrote:
> >>> On Mon, Jul 22, 2013 at 8:21 AM, Steffen Sledz <sledz@dresearch-fe.de
> >>> 
> >>> <mailto:sledz@dresearch-fe.de>> wrote:
> >>>> After being OE abstinent for some months i'd like to ask what is the
> >>>> current suggested method for recipes building from the HEAD revision of
> >>>> a git repository (we need this for continuous integration).
> >>>> 
> >>>> I read some RFC's in the ml about PKGV/PKGR stuff, but i miss a final
> >>>> decision, documentation and a good example.>
> >>> 
> >>> you can use ${AUTOREV} for this purpose. You can look at poky-bleeding
> >>> distro config for such an example.
> >>> 
> >>> e.g.
> >>> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto/conf/dist
> >>> r
> >>> o/include/poky-floating-revisions.inc
> >> 
> >> Hmmmm? This doesn't seem the work.
> >> 
> >> Here's what i tried in my recipe:
> >> 
> >> ------------> snip <------------
> >> PR = "r3"
> >> 
> >> SRCREV="${AUTOREV}"
> >> PV = "gitr${SRCPV}"
> >> ------------> snip <------------
> >> 
> >> But i get package versions like
> >> 
> >>   gitr0+53b64e717404d282d0c58b7fa4a4e74ab2ca81ba-r3
> >> 
> >> where SRCPB is always 0. :(
> >> 
> >> A bit more description and/or a complete example would be very helpful.
> > 
> > If you want these to increment now AIUI you need to be using the PR
> > server:
> > 
> > https://wiki.yoctoproject.org/wiki/PR_Service
> 
> And here comes my next really big problem. :(
> 
> We're sitting on an big, old but active project based on oe-classic and
> bitbake 1.12.0. Irksomely we're forced to switch from SVN to GIT for this
> project. So we need the AUTOREV/PRSERV stuff for this old environment too.
> 
> Has anyone tried to backport the feature to an older bitbake/oe-classic
> environment? Or can someone give some hints what's to do?

I'm not sure, but my gut feeling is you'd be better off trying to bring the 
project up to be based on OE-Core rather than trying to bring such 
functionality back to OE-Classic, particularly since for full functionality it 
requires signature-based tasks that are only supported with current versions 
of bitbake and require support from the metadata. You'd be trading some 
hopefully short-term pain for long-term gain if the project is going to 
continue for a reasonable amount of time.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


WARNING: multiple messages have this Message-ID (diff)
From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: Steffen Sledz <sledz@dresearch-fe.de>
Cc: openembedded-devel@lists.openembedded.org,
	openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] SRC_URI and latest HEAD revision with git (in oe-classic)
Date: Wed, 31 Jul 2013 13:50:56 +0100	[thread overview]
Message-ID: <8337615.XrjW46moIm@helios> (raw)
In-Reply-To: <51F8E0C2.3070102@dresearch-fe.de>

On Wednesday 31 July 2013 12:02:42 Steffen Sledz wrote:
> On 22.07.2013 11:51, Paul Eggleton wrote:
> > On Monday 22 July 2013 11:46:23 Steffen Sledz wrote:
> >> On 22.07.2013 11:01, Nicolas Dechesne wrote:
> >>> On Mon, Jul 22, 2013 at 8:21 AM, Steffen Sledz <sledz@dresearch-fe.de
> >>> 
> >>> <mailto:sledz@dresearch-fe.de>> wrote:
> >>>> After being OE abstinent for some months i'd like to ask what is the
> >>>> current suggested method for recipes building from the HEAD revision of
> >>>> a git repository (we need this for continuous integration).
> >>>> 
> >>>> I read some RFC's in the ml about PKGV/PKGR stuff, but i miss a final
> >>>> decision, documentation and a good example.>
> >>> 
> >>> you can use ${AUTOREV} for this purpose. You can look at poky-bleeding
> >>> distro config for such an example.
> >>> 
> >>> e.g.
> >>> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto/conf/dist
> >>> r
> >>> o/include/poky-floating-revisions.inc
> >> 
> >> Hmmmm? This doesn't seem the work.
> >> 
> >> Here's what i tried in my recipe:
> >> 
> >> ------------> snip <------------
> >> PR = "r3"
> >> 
> >> SRCREV="${AUTOREV}"
> >> PV = "gitr${SRCPV}"
> >> ------------> snip <------------
> >> 
> >> But i get package versions like
> >> 
> >>   gitr0+53b64e717404d282d0c58b7fa4a4e74ab2ca81ba-r3
> >> 
> >> where SRCPB is always 0. :(
> >> 
> >> A bit more description and/or a complete example would be very helpful.
> > 
> > If you want these to increment now AIUI you need to be using the PR
> > server:
> > 
> > https://wiki.yoctoproject.org/wiki/PR_Service
> 
> And here comes my next really big problem. :(
> 
> We're sitting on an big, old but active project based on oe-classic and
> bitbake 1.12.0. Irksomely we're forced to switch from SVN to GIT for this
> project. So we need the AUTOREV/PRSERV stuff for this old environment too.
> 
> Has anyone tried to backport the feature to an older bitbake/oe-classic
> environment? Or can someone give some hints what's to do?

I'm not sure, but my gut feeling is you'd be better off trying to bring the 
project up to be based on OE-Core rather than trying to bring such 
functionality back to OE-Classic, particularly since for full functionality it 
requires signature-based tasks that are only supported with current versions 
of bitbake and require support from the metadata. You'd be trading some 
hopefully short-term pain for long-term gain if the project is going to 
continue for a reasonable amount of time.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


  reply	other threads:[~2013-07-31 12:50 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-22  6:21 SRC_URI and latest HEAD revision with git Steffen Sledz
2013-07-22  9:01 ` Nicolas Dechesne
2013-07-22  9:46   ` Steffen Sledz
2013-07-22  9:51     ` Paul Eggleton
2013-07-22 10:30       ` Steffen Sledz
2013-07-22 11:08         ` Paul Eggleton
2013-07-22 12:42           ` Martin Jansa
2013-07-23  6:23           ` Steffen Sledz
2013-07-23  8:20             ` Paul Eggleton
2013-07-31 10:02       ` SRC_URI and latest HEAD revision with git (in oe-classic) Steffen Sledz
2013-07-31 10:02         ` [OE-core] " Steffen Sledz
2013-07-31 12:50         ` Paul Eggleton [this message]
2013-07-31 12:50           ` Paul Eggleton
2013-08-01  6:11           ` [oe] " Steffen Sledz
2013-08-01  6:11             ` [OE-core] " Steffen Sledz
2013-08-01 10:36             ` [oe] " Martin Jansa
2013-08-01 10:36               ` [OE-core] " Martin Jansa
2013-08-01 10:52               ` [oe] " Steffen Sledz
2013-08-01 10:52                 ` [OE-core] " Steffen Sledz
2013-08-01 11:37                 ` [oe] " Martin Jansa
2013-08-01 11:37                   ` [OE-core] " Martin Jansa

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=8337615.XrjW46moIm@helios \
    --to=paul.eggleton@linux.intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=sledz@dresearch-fe.de \
    /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.