All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: openembedded-core@lists.openembedded.org,
	Saul Wold <sgw@linux.intel.com>
Subject: Re: [CONSOLIDATED PULL 00/78] Review & ACK
Date: Fri, 26 Jul 2013 16:34:15 +0100	[thread overview]
Message-ID: <4930472.WmY8LRsmSd@helios> (raw)
In-Reply-To: <CAJTo0LZddy=dtdm_wdqg+GJQmxmt24uhmNe8J6hM6gnK_ikocw@mail.gmail.com>

On Friday 26 July 2013 10:35:20 Burton, Ross wrote:
> On 26 July 2013 08:14, Saul Wold <sgw@linux.intel.com> wrote:
> > Emilia Ciobanu (12):
> >   babeltrace: fix recipe name
> >   build-appliance-image: fix recipe name add GIT revision to PV variable
> >   chkconfig-alternatives-native: fix recipe name and add GIT revision to
> >   
> >     PV variable
> >   
> >   connman-gnome: fix recipe name add GIT revision to PV variable
> >   docbook-sgml-dtd-3.1-native: fix recipe name
> >   docbook-sgml-dtd-4.1-native: fix recipe name
> >   hwlatdetect: fix recipe name and add GIT revision to PV variable
> >   lttng-ust: fix recipe name and add GIT revision to PV variable
> >   mtd-utils: fix recipe name and add GIT revision to PV variable
> >   neard: fix recipe name
> >   rt-tests: fix recipe name add GIT revision to PV variable
> >   update-rc.d: fix recipe name and add GIT revision to PV variable
> 
> I meant to chime in on this yesterday but was... tied up.  For
> packages where the SRC_URI is a git repo *but* we're only ever
> checking out release tags do we really need to rename the package to
> _git?  The _git version to me implies "a mostly working snapshot of
> the development release" not "a stable release".

It's also going to be hard to be consistent in renaming everywhere as well 
because I think in a few cases we already have a bleeding-edge _git recipe in 
addition to the release recipe being built from git.

I guess I've not been very coherent on this, sorry for the confusion Emilia. I 
think we need to take a step back and make sure we're doing the right thing 
here, especially if we're only doing it to accommodate the current behaviour 
of distrodata.bbclass.

> >   bluez5: disable obex by default
> 
> The message seems to allude to some other reason for disabling it
> apart from a systemd user service not being packaged.  Is there a
> reason, as the systemd issue should be fixable in systemd.bbclass.
> 
> Apart from that, Acked-By: Ross Burton <ross.burton@intel.com>.

I've also looked over the rest of the patches, they're OK by me as well.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


  reply	other threads:[~2013-07-26 15:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-26  7:14 [CONSOLIDATED PULL 00/78] Review & ACK Saul Wold
2013-07-26  9:35 ` Burton, Ross
2013-07-26 15:34   ` Paul Eggleton [this message]
2013-07-29  6:10   ` 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=4930472.WmY8LRsmSd@helios \
    --to=paul.eggleton@linux.intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=sgw@linux.intel.com \
    /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.