From: Sujith H sujith_harida...@mentor.com
This is needed to deal with the situation where we're using ipk packaging, so
opkg-utils must be built regardless of what update-alternatives provider we
prefer. The downside to the current implementation is the need to adjust
PACKAGECONFIG as well as
On Fri, Aug 8, 2014 at 11:41 PM, Saul Wold s...@linux.intel.com wrote:
On 08/08/2014 02:37 AM, Sujith H wrote:
From: Sujith H sujith_harida...@mentor.com
This is needed to deal with the situation where we're using ipk
packaging, so
opkg-utils must be built regardless of what
From: Sujith H sujith_harida...@mentor.com
This is needed to deal with the situation where we're using ipk packaging, so
opkg-utils must be built regardless of what update-alternatives provider we
prefer. The downside to the current implementation is the need to adjust
PACKAGECONFIG as well as
On 08/08/2014 02:37 AM, Sujith H wrote:
From: Sujith H sujith_harida...@mentor.com
This is needed to deal with the situation where we're using ipk packaging, so
opkg-utils must be built regardless of what update-alternatives provider we
prefer. The downside to the current implementation is the
From: Sujith H sujith_harida...@mentor.com
This is needed to deal with the situation where we're using ipk packaging, so
opkg-utils must be built regardless of what update-alternatives provider we
prefer. The downside to the current implementation is the need to adjust
PACKAGECONFIG as well as
Hi Paul Eggleton,
On Thu, Aug 7, 2014 at 2:54 PM, Sujith H sujit...@gmail.com wrote:
From: Sujith H sujith_harida...@mentor.com
This is needed to deal with the situation where we're using ipk packaging,
so
opkg-utils must be built regardless of what update-alternatives provider we
prefer.
On 08/07/2014 02:24 AM, Sujith H wrote:
From: Sujith H sujith_harida...@mentor.com
This is needed to deal with the situation where we're using ipk packaging, so
opkg-utils must be built regardless of what update-alternatives provider we
prefer. The downside to the current implementation is the
From: Sujith H sujith_harida...@mentor.com
This is needed to deal with the situation where we're using ipk packaging, so
opkg-utils must be built regardless of what update-alternatives provider we
prefer. The downside to the current implementation is the need to adjust
PACKAGECONFIG as well as
From: Sujith H sujith_harida...@mentor.com
This is needed to deal with the situation where we're using ipk packaging, so
opkg-utils must be built regardless of what update-alternatives provider we
prefer. The downside to the current implementation is the need to adjust
PACKAGECONFIG as well as
On Wednesday 06 August 2014 17:34:09 Sujith H wrote:
From: Sujith H sujith_harida...@mentor.com
This is needed to deal with the situation where we're using ipk packaging,
so opkg-utils must be built regardless of what update-alternatives provider
we prefer. The downside to the current
On Wed, Aug 6, 2014 at 6:08 PM, Paul Eggleton paul.eggle...@linux.intel.com
wrote:
On Wednesday 06 August 2014 17:34:09 Sujith H wrote:
From: Sujith H sujith_harida...@mentor.com
This is needed to deal with the situation where we're using ipk
packaging,
so opkg-utils must be built
On Wednesday 06 August 2014 18:58:11 sujith h wrote:
On Wed, Aug 6, 2014 at 6:08 PM, Paul Eggleton paul.eggle...@linux.intel.com
wrote:
On Wednesday 06 August 2014 17:34:09 Sujith H wrote:
From: Sujith H sujith_harida...@mentor.com
This is needed to deal with the situation where
12 matches
Mail list logo
