On Wed, 11 Jan 2017 08:42:46 Aníbal Limón wrote:
> On 01/11/2017 02:59 AM, Paul Eggleton wrote:
> > On Thu, 05 Jan 2017 15:21:36 Aníbal Limón wrote:
> >> The new client/server API of tinfoil requires explicit call of
> >> shutdown method to send the event
.
This patch didn't apply against master - the databuilder piece does not appear
to be there.
Since it was a simple patch, I've remade the changes (with most of your commit
message) and pushed it to the paule/django18 branch that hopefully we'll be
moving over to soon.
Cheers,
ame to the conclusions you did - do you have any
suggestions on rewording?
I will say that the yocto-security@ list has been pretty quiet since it was
set up. Adding a few people on CC - are there any plans to make better use of
this list?
Cheers,
Paul
--
Paul
need to change for something
like this. I suspect you have inadvertently modified the configuration of that
(perhaps by setting TOOLCHAIN_HOST_TASK / TOOLCHAIN_TARGET_TASK globally?).
What does your cfgs/add-hals.conf actually set?
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
diting meta/conf/bitbake.conf or classes or any of the recipes
under meta/ - unless you plan to submit the changes back as generally
applicable improvements. The system is designed to allow you to isolate
your customisations in your own layer(s) and thus the core metadata can
be upgraded much more easily vs. you maintaining your own fork with your
changes in it.
Hope that helps - I'm happy to answer any further questions.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
s is simply
creating your own git repository and point to that in SRC_URI. Then the
patches become *much* more manageable.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
nt on the toolchain.
>
> When running bitbake gcc -e is see that this is the last match of
> RRECOMMENDS_gcc:
>
> RRECOMMENDS_gcc=" libssp libssp-dev "
>
>
> From: Paul Eggleton
> Sent: Monday, December 12, 2016 5:14 A
Hi Vincent,
On Wed, 14 Dec 2016 20:59:27 Vincent Rubiolo wrote:
> On 12/04/2016 11:14 AM, Paul Eggleton wrote:
> > Hmm, it looks like we're treating a byte array as a string (i.e. missing
> > decoding) and that doesn't work. Likely this broke during the Python3
> >
On Mon, 12 Dec 2016 08:41:36 Bruce Ashfield wrote:
> On 2016-12-11 02:33 PM, Paul Eggleton wrote:
> > Can we please have some automated tests covering all of this? Perhaps it
> > would be worth talking to Francisco Pedraza who is looking at adding
> > tests under bug
> &g
happen that this is still happening in poky.
Hmm, I just tried building an SDK (bitbake -c populate_sdk core-image-minimal)
with master and it definitely includes libssp_nonshared.a. Does the target
manifest for your SDK indicate libssp-dev is included?
Cheers,
Paul
--
Paul Eggleton
Inte
ild/tmp/work/cyclone5-poky-linux-gnu
> > eabi/linux-altera-ltsi/4.1.22-ltsi+gitAUTOINC+76bdba2700-r0/temp/log.do_ke
> > rnel_metadata.28274) ERROR: Task
> > (/home/gizero/work/decos/repo-master/poky/../meta-altera/recipes-kernel/li
> > nux/linux-altera-ltsi_4.1.22.bb:do_kernel_metadata) failed with exit code
> > '1'
> >
> > The commit in the patch remove the 'set +e' bits, but the following
> > legit code path expects the cmp command to have a non-zero return value.
>
> Aha. Indeed that is true. Clearly there aren't many people going
> through that path.
Can we please have some automated tests covering all of this? Perhaps it would
be worth talking to Francisco Pedraza who is looking at adding tests under bug
6359:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=6359
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
all of these libraries - they
should come in individually with the pieces that they're intended to be used
with. Hence I added an RRECOMMENDS as it seemed appropriate:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=1c0fc7fcf7772ef8774f623126050972f526fe83
In particular libssp is now RRECOMMENDED by g
code).
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
tion (i.e. files that get
installed into ${D} during do_install). So the determining factors for a file
going into the sysroot are (a) it has been installed into ${D} during
do_install and (b) it has been installed under one of a list of specific paths
as controlled by SYSROOT_DI
On Sun, 04 Dec 2016 22:41:29 Frank Meerkötter wrote:
> ANSI_X3.4-1968
That's strange - it should be "UTF-8". That's certainly what would cause this
problem. If you run "locale" what does that print?
Cheers,
Paul
--
Paul Eggleton
In
script -e -q -c "recipetool
> --color=always create --devtool -o /tmp/devtool238kzam0 '
> https://github.com/libuv/libuv.git' -x
> /home/fmee/hili_sdk/workspace/sources/devtoolsrcsme6hih0 -N libuv"
> /dev/null' failed
Unfortu
Hi Frank,
On Sun, 04 Dec 2016 20:24:01 Frank Meerkötter wrote:
> Am 04.12.2016 20:15 schrieb "Paul Eggleton" :
> > Hmm, it looks like we're treating a byte array as a string (i.e. missing
> > decoding) and that doesn't work. Likely this broke during the Python3
lue, or maybe your firewall/proxy is also
blocking access to our mirror.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
ol/create_buildsys_python.py",
> line 427, in replace_value
> new_value = re.sub(search, replace, value)
>File "/usr/lib64/python3.4/re.py", line 179, in sub
> return _compile(pattern, flags).sub(repl, string, count)
> TypeError: expected string or buffer
Hmm, i
to compare signatures when those have
changed. Find the siginfo / sigdata file for one of the early tasks that
executed and compare them to see what changed.
How are you setting SSTATE_MIRRORS in this scenario btw?
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
_
et specific to the build host, and if necessary _class-target to set things
specific to the target).
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
K (nativesdk-*) get different values
for MULTIMACH_TARGET_SYS as well, but this is accomplished by inheriting
the native or nativesdk classes or using BBCLASSEXTEND to create a variant
of the recipe for one or both.
> What options should I set in recipes?
Can you be more precise about what
e source unpacked by the build system does get removed under
certain circumstances and you don't want your changes to go with it.
Alternatively, if your configuration is temporary while you are making changes
to the source (or can be) then it would be worth checking out "devtool modify&
On Tue, 22 Nov 2016 10:44:48 Michel D'HOOGE wrote:
> > From: "Paul Eggleton"
> > Sent: Monday, 21 November, 2016 10:15:16 PM
> >
> > I suspect it has to do with the arch mapping that goes on in
> > meta/classes/package_deb.bbclass; it probably doesn&
es matching the current signatures of the tasks to be run, and if
available the packages will be unpacked instead of running the actual task.
This section of the reference manual may be helpful:
http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#shared-state-cache
Cheers,
Paul
--
On Mon, 21 Nov 2016 18:22:10 Michel D'HOOGE wrote:
> > From: "Paul Eggleton"
> > Sent: Friday, 18 November, 2016 2:46:07 AM
> >
> > I think the issue is this hasn't really been tested with deb
> > packaging. You
> > have hit a genu
s
package then perl will enter buildtools and you will experience other issues.
I think the issue is this hasn't really been tested with deb packaging. You
have hit a genuine bug though - would you mind filing a bug at
http://bugzilla.yoctoproject.org?
Thanks,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
org/releases/yocto/yocto-2.2/RELEASENOTES
>
> It would be helpful if morty could be added to the stable branch page, with
> clarification on whether jethro is being actively maintained:
>
> https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance
Done. We should really make this
that will be searched
for - not separate keywords.
Fixes [YOCTO #9879].
Signed-off-by: Paul Eggleton
---
layerindex/views.py | 16
1 file changed, 16 insertions(+)
diff --git a/layerindex/views.py b/layerindex/views.py
index 0933bf0..ae0220b 100644
--- a/layerindex/views.py
whole or an individual layer.
Update records older than 30 days are deleted automatically by default.
Signed-off-by: Paul Eggleton
---
TODO | 2 -
layerindex/admin.py | 8 +
layerindex/migrations/0005_layerupdate.py | 46
If you specified printerr=False we were referring to the output variable
that hadn't been set. Looks like I broke this back in 2013 in
93ce26f21cdbbd8a645792359cde87acf05144d7.
Signed-off-by: Paul Eggleton
---
layerindex/utils.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Add an action to duplicate a Branch object, along with all of the
LayerBranches (and LayerMaintainers and LayerDependencies) underneath
it.
Signed-off-by: Paul Eggleton
---
layerindex/admin.py | 26 ++
1 file changed, 26 insertions(+)
diff --git a/layerindex/admin.py b
t; > I added this line to my local.conf:
> >
> > GLIBC_GENERATE_LOCALES = "en_GB.UTF-8 en_US.UTF-8 en_GB en_US"
>
> you also need to set IMAGE_LINGUAS to include it into image
> e.g.
>
> GLIBC_GENERATE_LOCALES = "en-gb"
I guess you meant IMAGE
(and I just sent a
patch to disable building the eSDK without it).
> All that said, it is now working for me, time to learn to use it!
> Thanks for your help. Feel free to add my Acked-by or Signed-off-by
> to your patches if you wish.
>
> Acked-by: Gary Thomas
> Signed
esponder pointed out, the inherit of pkgconfig isn't needed
> > - you don't need pkg-config for anything being done here.
>
> Again, same error with or without this. Or even if I use " inherit
> bin_package"
Again, this isn't related to those erro
On Wed, 02 Nov 2016 03:02:11 Gary Thomas wrote:
> On 2016-11-02 02:44, Paul Eggleton wrote:
> > On Wed, 02 Nov 2016 02:37:57 Gary Thomas wrote:
> >> On 2016-11-01 21:33, Paul Eggleton wrote:
> >>> On Tue, 01 Nov 2016 13:36:57 Gary Thomas wrote:
> >>>
On Wed, 02 Nov 2016 02:37:57 Gary Thomas wrote:
> On 2016-11-01 21:33, Paul Eggleton wrote:
> > On Tue, 01 Nov 2016 13:36:57 Gary Thomas wrote:
> >> On 2016-10-31 23:06, Paul Eggleton wrote:
> >>> FYI the eSDK will use whatever you set in DISTRO - you have your own
&g
y on distros that aren't
on this list successfully, it's just that we can't commit to supporting all of
the included functionality on all of them.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
On Tue, 01 Nov 2016 13:36:57 Gary Thomas wrote:
> On 2016-10-31 23:06, Paul Eggleton wrote:
> > FYI the eSDK will use whatever you set in DISTRO - you have your own
> > distribution, but I assume you are still referencing poky - perhaps as an
> > include from your distro co
You're only unpacking a tarball, you don't need any build-time
dependencies to speak of. If you have runtime dependencies then set them in
RDEPENDS_${PN} since that's where runtime dependencies need to be set.
* As another responder pointed out, the inherit of pkgconfig isn't needed -
you don't need pkg-config for anything being done here.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
uffers
> /opt/runsb.sh
> /opt/README.txt
Ah, I think you need this line first in do_install:
install -d ${D}/opt/crank
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@y
On Tue, 01 Nov 2016 03:12:15 swapna.gurum...@microchip.com wrote:
> Thank you so much for your speedy response!!! Actually I ended up attaching
> an older bb file. I had some more modifications as attached. I changed
> license to close per your suggestion. Should I change FILES_${PN} to look
> like
list each
file unless you have more than one package and you want to split the files
among them.
* Is this really MIT licensed, or should the LICENSE in fact be "CLOSED"? Then
you wouldn't need to set LIC_FILES_CHKSUM either. (I'm assuming this is closed
source software y
On Mon, 31 Oct 2016 15:36:24 Khem Raj wrote:
> > On Oct 31, 2016, at 2:59 PM, Paul Eggleton
> > wrote:>
> > On Mon, 31 Oct 2016 09:37:07 Khem Raj wrote:
> >>> On Oct 31, 2016, at 7:37 AM, Vuille, Martin (Martin)
> >>> wrote:
> >>>
ea)
there isn't currently a means of host tools automatically getting pulled into
the SDK based on the target, though it has been discussed [1].
Cheers,
Paul
[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=5429
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
L into
glibc for nativesdk, so we should fix that - I've filed a bug [1] and will
sort that out. I think we should probably set the SDK_OLDEST_KERNEL default
for x86 to 2.6.32 at the same time - I assume there are no objections?
Cheers,
Paul
[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=
Ensure recent contributions from Mark and Liam are reflected in the
authors list.
Signed-off-by: Paul Eggleton
---
templates/layerindex/about.html | 2 ++
1 file changed, 2 insertions(+)
diff --git a/templates/layerindex/about.html b/templates/layerindex/about.html
index 3e98825..a290344
being used. At the moment only
cgit, gitweb, gitlab and "(custom)" (i.e. the current behaviour) are
supported. This is not a real field but activates javascript code
that sets the other fields and enables/disables the controls.
Signed-off-by: Paul Eggleton
---
layerindex/static/css/
Sometimes people put values that aren't URLs into the HOMEPAGE variable.
If that's the case, then we should not turn that value into a link which
will be invalid.
Signed-off-by: Paul Eggleton
---
layerindex/models.py | 6 ++
templates/layerindex/recipedetai
On Fri, 21 Oct 2016 14:34:31 Paul Eggleton wrote:
> On Thu, 20 Oct 2016 15:25:05 Paul Eggleton wrote:
> > I've been gathering material for the 2.2 release notes, here is what I
> > have
> > at the moment. Things missing:
> >
> > * Any new features/enhance
On Thu, 20 Oct 2016 15:25:05 Paul Eggleton wrote:
> I've been gathering material for the 2.2 release notes, here is what I have
> at the moment. Things missing:
>
> * Any new features/enhancements for the kernel tools - Bruce, is there
> anything worth noting?
>
> * K
On Wed, 19 Oct 2016 23:54:59 Bruce Ashfield wrote:
> On 2016-10-19 10:25 PM, Paul Eggleton wrote:
> > I've been gathering material for the 2.2 release notes, here is what I
> > have at the moment. Things missing:
> >
> > * Any new features/enhancements for th
know if there's any central resource we can use to find out which
versions of upstream software included which CVE fixes, or is it perhaps time
we started gathering links to the changelogs for each recipe? (Maybe we should
do the latter anyway.)
Cheers,
Paul
--
Paul Eggleton
In
On Wed, 19 Oct 2016 19:51:43 you wrote:
> On Wed, Oct 19, 2016 at 7:25 PM, Paul Eggleton
> wrote:
> > I've been gathering material for the 2.2 release notes, here is what I
> > have at the moment. Things missing:
> >
> > * Any new features/enhancements for
ed any of the items to be more understandable out of context as I have
with the features/enhancements.
Let me know if I've missed or misrepresented anything.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
New Features / Enhancements
--
results in order to fix this.
Fixes [YOCTO #10177].
Signed-off-by: Paul Eggleton
---
layerindex/utils.py | 10 ++
layerindex/views.py | 9 -
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/layerindex/utils.py b/layerindex/utils.py
index 484d3fe..e3be631 100644
Improves slightly on 3155206e54413f72df3b3b41280eafd332a58ba4 by doing
an exact match on name and showing that first - now when you search for
"git" you really do get the git recipe first in the list.
Signed-off-by: Paul Eggleton
---
layerindex/views.py | 9 +++--
1 file
typically inherited from individual recipes with
inherit - there are classes that are usually applied globally by adding their
names to INHERIT (e.g. buildhistory).
Hope that helps.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
On Mon, 17 Oct 2016 15:41:04 akuster808 wrote:
> On 10/17/2016 02:34 PM, Paul Eggleton wrote:
> > On Mon, 17 Oct 2016 15:23:55 Bruce Ashfield wrote:
> >> On 2016-10-17 03:11 PM, Sona Sarmadi wrote:
> >>> From https://wiki.yoctoproject.org/wiki/Stable_branch_mainte
en forgot to go back and do that? master (and the stable
release that eventually follows from it) would potentially be left without the
fix, so when you upgraded the vulnerability would come back.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
other changes in operation)?
It doesn't need to be polished, Scott Rifenbark will take care of that. Just
replying to this email with Scott on CC should be sufficient.
Thanks,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto ma
ed, Oct 12, 2016 at 11:55 AM, Vijayakumar Badiger <
>
> vijayakuma...@gmail.com> wrote:
> > Thanks Paul, appreciate your reply.
> >
> > Cheers,
> > Vijay
> >
> >
> > On Mon, Oct 10, 2016 at 6:24 PM, Paul Eggleton <
> >
> > paul.eg
Hi folks,
Would someone be able to help Scott with the background for this:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=8596
It's not really my area of expertise and we really want this documented
properly once and for all.
Thanks,
Paul
--
Paul Eggleton
Intel Open Source Techn
rk - however it's fair to say it does not receive the same
level of testing that 5.3 does given that 5.3 is the default.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
On Tue, 11 Oct 2016 09:19:15 Paul Eggleton wrote:
> On Mon, 10 Oct 2016 12:47:11 Mark Hatle wrote:
> > On 10/10/16 12:37 PM, Paul Eggleton wrote:
> > > On Mon, 10 Oct 2016 04:48:41 Hatle, Mark wrote:
> > >>> On Oct 10, 2016, at 2:54 AM, Paul Eggleton
> > &
On Mon, 10 Oct 2016 12:47:11 Mark Hatle wrote:
> On 10/10/16 12:37 PM, Paul Eggleton wrote:
> > On Mon, 10 Oct 2016 04:48:41 Hatle, Mark wrote:
> >>> On Oct 10, 2016, at 2:54 AM, Paul Eggleton
> >>>
> >>>
> >>> wrote:
> >>>>
On Mon, 10 Oct 2016 04:48:41 Hatle, Mark wrote:
> > On Oct 10, 2016, at 2:54 AM, Paul Eggleton
> > wrote:
> >> On Fri, 07 Oct 2016 13:20:50 Mark Hatle wrote:
> >> FYI, I have made sure these are re-based on top of paule/django18 and
> >> pushed to:
> >
n tinfoil to avoid bitbake complaining about multiple instances.
That last bit of the commit message is now invalid in v2.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproje
comments, a lot don't use them at all. Technically being a variable,
DISTRO_NAME could be set in an inc file rather than the distro conf file, and
often it is, so we should really parse to get it rather than scraping it.
(I'm happy if we sort this out as a later impro
ck on "Layer branches" I get:
no such column: layerindex_layerbranch.collection
I'm afraid we really do need to create migrations whenever we change the
models.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
_
d happen - these files would normally be part of
the ${PN}-dbg package, but since you've removed that from PACKAGES, they are
ending up unpackaged and that is not allowed.
Like the other responder I would suggest you not set PACKAGES - instead you
just need to take steps so that the .so file
is that correct?
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
ings and what to do about them:
http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#qa-errors-and-warnings
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
;).
Also, any change to the structure needs to be accompanied by a migration to
handle existing databases. Since you're working with Django 1.8 you'd be
creating its migrations rather than South's, and we had to start with a clean
slate for that so I can
release (it's
not expected that you'd have datastores still around and be parsing recipes
when tinfoil has been shut down), so we *really* need to try to avoid shutting
down like this. Can you explain what you saw?
Cheers,
Paul
--
Paul Eggleto
ils.vercmp_string_op(layer_ver, version_str,
> operator)
> +except bb.utils.VersionStringException as vse:
> +raise vse
> +
> +if success:
> +return layerbranch.layer
> +
> + return None
> +
> +def add_dependencies(la
particular reason you didn't omit the
initial assignment and do this instead:
cln = ', '.join(conflict_list_urls)
>
> +if not layer_paths:
> +logger.error('No layers added.')
> +sys.exit(1);
> +
Indenting is out here (sh
@@ -222,6 +224,10 @@ def main():
> if layer_name.endswith('.git'):
> layer_name = layer_name[:-4]
>
> +if not valid_layer_name.match(layer_name):
> +logger.error('Invlaid layer name "%s" - Layer name can only
> inc
tory (if one exists) as the name.
Looks good, but the two dryrun blocks have incorrect indenting.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
u're
always looking the most recent stable version of the manual:
http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto m
clude bind-extas
> in your image.
The bind-utils package is already split out and packages dig and host, so I
would suggest installing that rather than the main bind package. nslookup
isn't being packaged at all, I suspect we are relying on the busybox stub
n u-boot recipe.
If you plan on maintaining this layer then it would be great if you could
submit it to the OE layer index (at http://layers.openembedded.org ).
Thanks,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing l
registering new accounts but that too should be sorted in
the next day or so. Sorry about the delay.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
me a bit is that my project RDEPENDs python3 and python3
> RDEPENDs python3-core, so I would have thought this would have propagated!
I think it does, it may just be that the code that generates the warning isn't
smart enough to figure that out.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
or simply bitbake -e
> and grep for this change
>
>
>
> Thanks & Regards,
> Hari Prasath
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
rm - you'll be able to see not just the final value but the
history of how the value got set.
To avoid this you'll likely need to set your OLDEST_KERNEL value with an
override - the machine name should work i.e. assuming your MACHINE is "pine64"
you would do:
OLDEST_K
at its a mess - both from a usage perspective and looking at the
code. It was disappointing to us because initially it looked like it was going
to solve a lot of our problems. Maybe others have had different experiences -
I'd love to hear details if anyone is prepar
].
Signed-off-by: Paul Eggleton
---
layerindex/tools/import_classic.py | 11 +++
layerindex/update_layer.py | 17 ++---
2 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/layerindex/tools/import_classic.py
b/layerindex/tools/import_classic.py
index ee9924
If you're in a virtualenv it doesn't make a difference, but outside of
one it will.
Signed-off-by: Paul Eggleton
---
README | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/README b/README
index fa5c3b2..8437089 100644
--- a/README
+++ b/README
@@ -47,15 +47,1
With Python 3 we need to take care of decoding the output so we can
treat it as a string. At the same time, it's more useful to see the
output string rather than the exception if there is some output.
Signed-off-by: Paul Eggleton
---
layerindex/views.py | 3 +++
1 file changed, 3 inser
1d76228675e93add50dd5216c43e00f977e1aaa8:
Use functools.reduce instead of reduce (2016-07-04 09:51:21 +1200)
are available in the git repository at:
git://git.yoctoproject.org/layerindex-web paule/mc-fixes
http://git.yoctoproject.org/cgit.cgi/layerindex-web/log/?h=paule/mc-fixes
Paul Eggleton (3):
Use
date them.
>
> ping?
I completely missed this until now, sorry - I've just applied it to the master
and krogoth branches.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
http
On Thu, 25 Aug 2016 18:14:23 Andreas Müller wrote:
> On Wed, Jul 13, 2016 at 6:00 AM, Paul Eggleton
> wrote:
> > On Fri, 19 Feb 2016 08:05:09 Andreas Müller wrote:
> >> On Wed, Feb 3, 2016 at 9:06 PM, Andreas Müller
> >> wrote:
> >> > On
#x27;t expect it to be because it's locked. It may or may not be related to the
use of an external toolchain - I'm not sure because it's not a scenario I have
tested.
Are the layers / toolchain you are using downloadable, i.e. could I reproduce
the issue here?
sage
> > PSPLASH_STARTUP_MSG_FILE .. path to the file to read
> >
> > Signed-off-by: Richard Leitner
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
f693753
Could you apply this and check if it fixes the issue? If so we'll backport it.
Thanks,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Embedded#Streamlining_git-send-email_with_configuration
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
is sort of thing shouldn't happen. Could you perhaps file a bug
for this with more details?
Thanks,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
e - that's the 2.1 buildtools so it contains Python 2, not 3.
We do have the 2.2 M1 version that does contain Python 3:
http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-2.2_M1/buildtools/poky-glibc-x86_64-buildtools-tarball-core2-64-buildtools-nativesdk-standal
hing to consider is that any _poky overrides will only be applied if
DISTRO = "poky", thus include/require of poky.conf won't incorporate those
into your custom distro. You can set DISTROOVERRIDES to include "poky" to
counter this. In practice though there aren't too
301 - 400 of 1699 matches
Mail list logo
