uild found there's (almost?)
always a link to the build log.
--
-Joe MacDonald.
:wq
signature.asc
Description: PGP signature
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
ion of the patchset if applicable. Please ensure you add/increment the
> version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
> [PATCH v3] -> ...).
>
> ---
> Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
> Test suite:
Based on the blacklist behaviour, recipes can be tagged as deprecated.
Such recipes will produce a warning message when included in a build but
unlike blacklisted recipes, the build will continue.
Signed-off-by: Joe MacDonald
---
Literally no different than v1, differs from v3 in that the
[Re: [OE-core] ✗ patchtest: failure for deprecated.bbclass: Add a PNDEPRECATED
variable for recipes (rev3)] On 17.02.27 (Mon 14:25) Leonardo Sandoval wrote:
> On Mon, 2017-02-27 at 15:06 -0500, Joe MacDonald wrote:
> > [✗ patchtest: failure for deprecated.bbclass: Add a PNDEPRECATED
sion number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
> [PATCH v3] -> ...).
>
> ---
> Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
> Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe
>
--
-Joe MacDonald.
:wq
Based on the blacklist behaviour, recipes can be tagged as deprecated.
Such recipes will produce a warning message when included in a build but
unlike blacklisted recipes, the build will continue.
Signed-off-by: Joe MacDonald
---
v2: Included documentation for new variable
v3: Refreshed to
pletely
> > new recipe for it, or we see someone restoring these recipes (e.g. in
> own
> > layers instead of fixing
> > the PNBLACKLIST/PNDEPRECATED reasons in original layer).
> >
> > On Fri, Feb 24, 2017 at 5:55 AM, Khem
Based on the blacklist behaviour, recipes can be tagged as deprecated.
Such recipes will produce a warning message when included in a build but
unlike blacklisted recipes, the build will continue.
Signed-off-by: Joe MacDonald
---
documentation/ref-manual/ref-classes.xml | 28
Based on the blacklist behaviour, recipes can be tagged as deprecated.
Such recipes will produce a warning message when included in a build but
unlike blacklisted recipes, the build will continue.
Signed-off-by: Joe MacDonald
---
I threw this together a long time ago and never got around to
When devtool creates a new workspace, it produced a README with one very
long line and no space following 'bblayers.conf'. Add a line break as was
intended.
Signed-off-by: Joe MacDonald
---
scripts/devtool | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts
he 'virtual/'
prefix preserves the intent, while not requiring it to be removed for
package systems that allow it (eg. opkg and rpm).
Signed-off-by: Joe MacDonald
---
meta/classes/package_deb.bbclass | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/meta
g the
specific package and flag that fails.
Signed-off-by: Joe MacDonald
---
meta/classes/base.bbclass | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index f078001..d711ae4 100644
--- a/meta/classes/base.bbclass
+++ b/meta/cl
libpcap was not previously installing a pkg-config file. Add a basic one
that will allow using 'pkg-config --libs libpcap', for example, in recipes
rather than 'pcap-config', which frequently returns incorrect information.
Signed-off-by: Joe MacDonald
---
Hmm, pretty sur
; dvb-apps-1.1.1: dvbnet requires libdvbapi.so()(64bit), but no providers in
>> its RDEPENDS [file-rdeps]
>> dvb-apps-1.1.1: dvbnet requires libdvbapi.so, but no providers in its
>> RDEPENDS [file-rdeps]
>> dvb-apps-1.1.1: dvbtraffic requires libdvbapi.so()(64bit), but no providers
>> in its RDEPENDS [file-rdeps]
>> dvb-apps-1.1.1: dvbtraffic requires libdvbapi.so, but no providers in its
>> RDEPENDS [file-rdeps]
>> emacs-23.4: emacs requires /usr/bin/perl, but no providers in its RDEPENDS
>> [file-rdeps]
>> fakeroot-1.18.4: fakeroot requires /bin/bash, but no providers in its
>> RDEPENDS [file-rdeps]
>> fbida-2.09+gitAUTOINC+6aa5563cb3: fbida requires /bin/bash, but no providers
>> in its RDEPENDS [file-rdeps]
>> foxtrotgps-1.1.1: foxtrotgps requires /usr/bin/python, /usr/bin/perl, but no
>> providers in its RDEPENDS [file-rdeps]
>> gammu-1.32.0: gammu requires /bin/bash, but no providers in its RDEPENDS
>> [file-rdeps]
>> gammu-1.32.0: gammu-dev requires /bin/bash, but no providers in its RDEPENDS
>> [file-rdeps]
>> gateone-1.2: gateone requires /bin/bash, but no providers in its RDEPENDS
>> [file-rdeps]
>> giflib-4.1.6: giflib-utils requires /usr/bin/perl, but no providers in its
>> RDEPENDS [file-rdeps]
>> gnome-desktop-2.32.1: gnome-desktop requires /usr/bin/python, but no
>> providers in its RDEPENDS [file-rdeps]
>> gnome-panel-2.32.1: gnome-panel requires /usr/bin/python, but no providers
>> in its RDEPENDS [file-rdeps]
>> groff-1.22.2: groff requires /bin/sed, but no providers in its RDEPENDS
>> [file-rdeps]
>> gupnp-0.20.12: gupnp-dev requires /usr/bin/python, but no providers in its
>> RDEPENDS [file-rdeps]
>> hplip-3.12.6: hplip-filter requires /usr/bin/perl, but no providers in its
>> RDEPENDS [file-rdeps]
>> ipvsadm-1.26: ipvsadm requires /bin/bash, but no providers in its RDEPENDS
>> [file-rdeps]
>> libbonobo-2.32.1: libbonobo requires /usr/bin/perl, but no providers in its
>> RDEPENDS [file-rdeps]
>> libnewt-0.52.18: whiptail requires libnewt.so()(64bit), but no providers in
>> its RDEPENDS [file-rdeps]
>> libnewt-0.52.18: whiptail requires libnewt.so, but no providers in its
>> RDEPENDS [file-rdeps]
>> libnewt-python-0.52.18: libnewt-python requires libnewt.so()(64bit), but no
>> providers in its RDEPENDS [file-rdeps]
>> libnewt-python-0.52.18: libnewt-python requires libnewt.so, but no providers
>> in its RDEPENDS [file-rdeps]
>> lio-utils-4.1+gitAUTOINC+28bd928655: lio-utils requires /bin/bash, but no
>> providers in its RDEPENDS [file-rdeps]
>> lmsensors-config-1.0: lmsensors-config-cgi requires /usr/bin/rrdcgi, but no
>> providers in its RDEPENDS [file-rdeps]
>> nodejs-0.8.18: nodejs requires /bin/bash, but no providers in its RDEPENDS
>> [file-rdeps]
>> numptyphysics-0.2+svnr109: numptyphysics requires /bin/bash, /usr/bin/perl,
>> but no providers in its RDEPENDS [file-rdeps]
>> opensaf-4.5.0: opensaf requires /bin/bash, /usr/bin/python, but no providers
>> in its RDEPENDS [file-rdeps]
>> packagekit-0.5.6: packagekit requires /bin/bash, but no providers in its
>> RDEPENDS [file-rdeps]
>> pcsc-lite-1.8.6: pcsc-lite requires /usr/bin/python, but no providers in its
>> RDEPENDS [file-rdeps]
>> pm-qa-0.4.14: pm-qa requires /bin/bash, but no providers in its RDEPENDS
>> [file-rdeps]
>> qt-creator-2.8.1: qt-creator requires /usr/bin/perl, but no providers in its
>> RDEPENDS [file-rdeps]
>> tracker-0.14.2: tracker-nautilus-extension requires
>> libnautilus-extension.so.1()(64bit), but no providers in its RDEPENDS
>> [file-rdeps]
>> tracker-0.14.2: tracker-nautilus-extension requires
>> libnautilus-extension.so.1, but no providers in its RDEPENDS [file-rdeps]
>> ubx-utils-0.0.0+gitrAUTOINC+b63c0932dd: ubx-utils requires /bin/bash, but no
>> providers in its RDEPENDS [file-rdeps]
>> unionfs-fuse-0.26: unionfs-fuse requires /bin/bash, but no providers in its
>> RDEPENDS [file-rdeps]
>> usbpath-0.0+svnr3172: usbpath requires /usr/bin/perl, but no providers in
>> its RDEPENDS [file-rdeps]
>> wvstreams-4.6.1: wvstreams requires /usr/bin/perl, but no providers in its
>> RDEPENDS [file-rdeps]
>>
>>
>> count: 0 issue: version-going-backwards
>> --
>> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
>
>
>
> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
--
Joe MacDonald
:wq
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
.
It is used by several ISPs to provide L2TP services and by corporations
to implement L2TP VPNs.
Signed-off-by: Li Xin
Signed-off-by: Joe MacDonald
---
Martin:
This is basically just a minor clean-up of the earlier openl2tp recipe. So
far I've been unable to reproduce the error rep
A minor typo was causing LAYERDEPENDS to be overwritten instead of
appended to in our layer.conf.
Signed-off-by: Joe MacDonald
---
meta-networking/conf/layer.conf | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta-networking/conf/layer.conf b/meta-networking/conf
libxml2 prior to 2.9.2.
References:
http://www.openwall.com/lists/oss-security/2014/10/17/7
https://www.ncsc.nl/actueel/nieuwsberichten/kwetsbaarheid-ontdekt-in-libxml2.html
Signed-off-by: Joe MacDonald
---
meta/recipes-core/libxml/libxml2.inc | 1 +
.../libxml/libxml2
list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
> [signaturel]
> Get your own FREE website, FREE domain & FREE mobile app withKnow More
> Company email.
2013-10-319 17 19 74 114 107 23 21
> 14
> 2013-10-3011 16 18 224 191 184 28 23
> 16
>
>
--
-Joe MacDonald.
:wq
signature.asc
Description: Digital signature
_
cache fetches, mask off BB_NO_NETWORK for the local function.
Signed-off-by: Joe MacDonald
---
meta/classes/sstate.bbclass | 10 ++
1 file changed, 10 insertions(+)
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 28dc312..c1ca54b 100644
--- a/meta/cl
state mirror fetch attempts we will temporarily mask off
BB_NO_NETWORK, allowing the fetch to complete for the sstate object, but still
disable network access for remote sources.
--
-Joe MacDonald.
:wq
___
Openembedded-core mailing list
Openembedd
On Wed, Jun 19, 2013 at 11:02 AM, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> On Wed, 2013-06-19 at 10:50 -0400, Joe MacDonald wrote:
> > Adding the oe-core list back to the cc list since I accidentally
> > dropped the list on my first response.
> >
Adding the oe-core list back to the cc list since I accidentally dropped
the list on my first response.
On Wed, Jun 19, 2013 at 10:37 AM, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> On Wed, 2013-06-19 at 10:15 -0400, Joe MacDonald wrote:
> >
> >
> >
gt; None of them seems perfect. Is there already some policy?
>
> jesse
>
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listi
On Thu, Aug 23, 2012 at 2:22 AM, Koen Kooi wrote:
>
> Op 22 aug. 2012, om 21:22 heeft Chris Larson het volgende
> geschreven:
>
>> On Wed, Aug 22, 2012 at 11:59 AM, Joe MacDonald wrote:
>>> On Wed, Aug 22, 2012 at 2:20 PM, Christopher Larson
>>> wrote:
&
On Wed, Aug 22, 2012 at 3:37 PM, Joe MacDonald wrote:
> On Wed, Aug 22, 2012 at 3:22 PM, Chris Larson wrote:
>> On Wed, Aug 22, 2012 at 11:59 AM, Joe MacDonald wrote:
>>> On Wed, Aug 22, 2012 at 2:20 PM, Christopher Larson
>>> wrote:
>>>> On Friday,
On Wed, Aug 22, 2012 at 3:22 PM, Chris Larson wrote:
> On Wed, Aug 22, 2012 at 11:59 AM, Joe MacDonald wrote:
>> On Wed, Aug 22, 2012 at 2:20 PM, Christopher Larson
>> wrote:
>>> On Friday, June 15, 2012 at 8:15 AM, Joe MacDonald wrote:
>>>
>>> We
On Wed, Aug 22, 2012 at 2:20 PM, Christopher Larson wrote:
> On Friday, June 15, 2012 at 8:15 AM, Joe MacDonald wrote:
>
> We've been talking about this on-and-off at Wind River for a while now,
> but it now seems like a reasonable time to bring a proposal to the OE
> commu
On Fri, Jun 15, 2012 at 3:55 PM, Philip Balister wrote:
> On 06/15/2012 02:55 PM, Andrei Gherzan wrote:
>> On Fri, Jun 15, 2012 at 9:08 PM, Otavio Salvador
>> wrote:
>>
>>> On Fri, Jun 15, 2012 at 12:42 PM, Khem Raj wrote:
I think creating a networking layer is fine idea, alongside meta-oe,
hin a few days
of consensus.
So what does everyone think? Awesome idea? Terrible idea? (Hopefully)
something in between? All feedback is welcome.
--
Joe MacDonald, Sr. Member of Technical Staff, Linux Products Group, Wind River
direct 613.270.5750 mobile 613.291.7421
30 matches
Mail list logo
