On 25.09.22 11:41, Richard Purdie wrote:
On Sun, 2022-09-25 at 10:53 +0200, Konrad Weihmann wrote:
Hi all,
On 24.09.22 04:02, Lee Chee Yang wrote:
Hi
We are pleased to announce the third milestone release for Yocto Project
4.1 (yocto-4.1_M3) is now available for download.
Download:
http
Hi all,
On 24.09.22 04:02, Lee Chee Yang wrote:
Hi
We are pleased to announce the third milestone release for Yocto Project
4.1 (yocto-4.1_M3) is now available for download.
Download:
http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-4.1_M3
Hi all,
is there a way to set the package metadata in a way that it would
require one of the packages providing a tool via the ALTERNATIVE_ mechanism?
E.g. sed for instance could be provided by busybox (if enabled in
config) or by the standalone sed recipe - within my recipe I would just
still does not build:
ERROR: smbus-*-*.whl is not a valid wheel filename.
Best regards,
Matthias
-Ursprüngliche Nachricht-
Von: Konrad Weihmann
Gesendet: Montag, 28. Februar 2022 13:59
An: Matthias Klein ; yocto@lists.yoctoproject.org
Betreff: Re: AW: [yocto] python3-smbus no longer bui
.
Try
PYPA_WHEEL = "${PIP_INSTALL_DIST_PATH}/smbus-*-*.whl"
instead - and it should really work
Best reagrds,
Matthias
-Ursprüngliche Nachricht-
Von: Konrad Weihmann
Gesendet: Montag, 28. Februar 2022 13:51
An: Matthias Klein ; yocto@lists.yoctoproject.org
Betreff: Re: [yoct
Hi Matthias,
this is cause by merged PEP-517 changes.
To make it build again just inject
PIP_INSTALL_PACKAGE = "smbus"
into the recipe or a bbappend.
Mainly the python3-prefix of the recipe, makes the name guessing fail, I
suspect patches to be incoming soon
BR
Konrad
On 28.02.22 13:45,
On 27.01.22 15:43, Alexander Kanavin wrote:
Reviewed-by: Martin Kaistra
Signed-off-by: Alexander Kanavin
---
COPYING.MIT | 17 +
README | 23 +++
conf/layer.conf | 19 +++
3 files changed, 59 insertions(+)
create mode
Fairly easy, each distro creates an OVERRIDE by default, so you could do
A:poky = "foo.service"
A:yourdistro = "bar.service"
SYSTEMD_PACKAGES = "${A}"
do_install:append() {
install -d ${D}${systemd_system_unitdir}
install -m 0644 ${WORKDIR}/${A} ${D}${systemd_system_unitdir}
}
The following I just found in local.conf.sample.extended
# Enabling FORTRAN
# Note this is not officially supported and is just illustrated here to
# show an example of how it can be done
# You'll also need your fortran recipe to depend on libgfortran
FORTRAN:forcevariable = ",fortran"
guess
I think the reason of that is that fortran support isn't enabled in
default gcc-runtime recipe.
from gcc-runtime.inc:
RUNTIMETARGET = "${RUNTIMELIBSSP} libstdc++-v3 libgomp libatomic
${RUNTIMELIBITM} \
${@bb.utils.contains_any('FORTRAN', [',fortran',',f77'],
'libquadmath', '', d)} \
"
Hi,
according to my understanding BUILDNAME should not be used like that
since f85f1ef24e59c0c058f96f0dfa82e50969fd580b in bitbake.
The variable should contain only references to other automatically
determined variables (default = ds.setVar("BUILDNAME", "${DATE}${TIME}")
Judging from that
You can either use BBMASK in your local.conf to remove the bbappend from
the parsing tree or set BB_DANGLINGAPPENDS_WARNONLY in your specific build.
both can be added to your specific kas yaml without any issues
[1]
On 29.11.21 16:14, Armin Kuster wrote:
Signed-off-by: Armin Kuster
---
recipes-security/fail2ban/python3-fail2ban_0.11.2.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-security/fail2ban/python3-fail2ban_0.11.2.bb
The super yoctoish way would be to alter the packaging of the recipe to
your needs.
Let's assume recipe-a consists of the files
foo
bar
and it would package both files into recipe-a pkg.
In the actual image you only install packages into a file system, so if
you don't want bar to be
No there isn't - with the yocto project you can build your own
distribution not mimic other already available distributions.
If you want to build Ubuntu you have to ask canonical.
On 25.10.21 09:41, keyurthumar0...@gmail.com wrote:
I want to build ubuntu distro using yocto.
Is there a way
On 21.09.21 16:18, Lijun Chen wrote:
Hi,
I would like to include libgtest.so into my Yocto image. I added
googletest to IMAGE_INSTALL and added the following line to
sources/meta-openembedded/meta-oe/recipes-test/googletest/googletest_git.bb:
EXTRA_OECMAKE = "-DBUILD_SHARED_LIBS=ON "
The
If you're sure you only use standard python libs it's fairly easy.
make a recipe (name it how ever you like)
SCR_URI = "file://.py"
do_install() {
install -m 0755 .py ${bindir}/.py
}
RDEPENDS:${PN} += "python3-core"
in the image
IMAGE_INSTALL += ""
---
if your script needs further
The file in called COPYING.txt in this archive [1] not LICENSE
[1]https://files.pythonhosted.org/packages/a9/d9/9fdfb0ac2354d059e466d562689dbe53a23c4062019da2057f0eaed635e0/pyinstaller-4.5.1.tar.gz
On 20.08.21 13:57, yasminebenghoz...@gmail.com wrote:
Hello,
So I've been trying to build a
On 12 May 2021 14:51, Chuck Wolber wrote:I got a fetcher failure on go-systemd today, which puzzled me. That
recipe has not changed in ages, and the SRCPV hash is clearly visible
in the repository.
After looking at it closer, it seems that github.com/coreos/go-systemd
has changed its
On 11.05.21 18:14, Bel Hadj Salem Talel wrote:
Hi All,
I integrated python3-numpy in my image and when trying to import it I
get this error: (python3 version: 3.7.7)
--
>>> import cv2
OpenCV bindings requires "numpy" package.
Install it via command:
pip install numpy
Traceback (most
Well AFAIK your observation is correct, go-mod.bbclass doesn't work a in
BB_NO_NETWORK-safe manner.
What you could do is to provide all the dependencies manually and add
them via DEPENDS, which is grant the behavior expected.
The bad thing about go is that chances of circular dependencies of
buildstats [1] maybe? That can be inherited globally and does give some
neat results and insights
[1]
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/buildstats.bbclass
On 15.02.21 21:08, rustyhow...@gmail.com wrote:
Is there a way to automatically record build time of a
The issue here is that you are overwriting the DEPENDS after the inherit.
Two ways to solve this problem
Either use
DEPENDS = "python3-astropy-helpers"
PYPI_PACKAGE = "astropy"
inherit pypi
or
PYPI_PACKAGE = "astropy"
inherit pypi
DEPENDS += "python3-astropy-helpers"
python3-setuptools
Just a wild guess, but could your corporate proxy, which is kind of
visible in the provided logs, intervene with this - to me it seems to be
some MITM box.
Do you have any chance to try it without that proxy involved?
On 19.01.21 21:42, Monsees, Steven C (US) via lists.yoctoproject.org wrote:
Hi all,
I have a few oeqa test cases, which always should run last in a test
suite (log and file collectors for instance).
Due to the ordering of the test case discovery I had to name all those
tests like "zzz_" to move them to the end of the computed list.
Unfortunately this is very error
Hi all,
I have a bunch of custom testcases (oeqa/runtime/cases) which are
interacting with "d" from the build host - basically fetching some info
while executing the test, e.g.
foo = self.tc.td['MY_CUSTOM_VAR']
What I've seen is that these files create python __pycache__ files
during
I would recommend that you go for a systemd drop-in file [1].
That would be something like a small snippet placed to
/etc/systemd/system/dbus-org.bluez.service/override.conf
In that file place something like
[Service]
ExecStart=
ExecStart=
this way you don't need to alter the upstream recipe
te:
Thanks to Konrad Weihmann, we have some communication occurring with the
Python pypa folks about an important change in Python packaging [1][2].
This change is defined in PEP 517 [3][4]. Essentially, setup.py files
will go away and wheels will be preferred over eggs. To make this more
straig
Just add RDEPENDS_${PN] += "python3-json" to the recipe that creates the
package, that contains the mentioned python script.
Alternatively add IMAGE_INSTALL += "python3-json" to the image the
script is in.
As this is a core module (shipped by python3) the mapping is purely
based on the
The service is deployed with standard systemd package, which doesn't
have that set as far as I see it (no SYSTEMD_AUTO_ENABLE_${PN} in the
latest recipe revision)
I think, after browsing through the code of systemd - this "autostart"
behavior comes from [1].
So I would say you can disable it
Hi,
I would recommend that you go for a systemd drop-in file [1].
That would be something like a small snippet placed to
/etc/systemd/system/avahi-daemon.service.d/override.conf
In that file place something like
[Service]
ExecStart=
ExecStart=
this way you don't need to alter the upstream
Thanks to both of you - seems like I missed out on BB_LOGCONFIG, but
it's exactly what I was looking for.
Regards
Konrad
On 24.08.20 15:59, Joshua Watt wrote:
On 8/24/20 8:26 AM, Richard Purdie wrote:
On Mon, 2020-08-24 at 08:10 -0500, Joshua Watt wrote:
The newer log handling uses Python's
Hi all,
when running bitbake in CI I would like to add an additional log handler
to used python logging to catch *ALL* (task warnings, dangling append,
qa issues, a.s.o.), instead of manually grepping through the console log.
The information coming from this should be ideally be written to a
Did you had a look at
https://github.com/kraj/meta-openwrt/blob/master/recipes-networking/ipset/ipset_6.38.bb
yet?
That pretty much looks like the one you were looking for, but for an
older version, right?
Maybe you can try to use that recipe as a basis for your update package
On 17.08.20
Hi Armin,
that sounds good. Please keep me in the loop.
BTW did you/the project create any kind of roadmap, just out of interest?
BR
Konrad
On 02.08.20 17:24, akuster808 wrote:
On 8/2/20 2:47 AM, Konrad Weihmann wrote:
Hi,
is this just a demo, or are there plans to broaden the scope
Hi,
is this just a demo, or are there plans to broaden the scope of this layer?
To me it would make perfectly sense to have more of these features
(besides sudo, openssh and root-pwd) and I'm willing to contribute, if
this is something that will be actively pursued by the project.
IMHO this
I think some RDEPENDS entries are missing, by looking at
https://github.com/googleapis/oauth2client/blob/master/setup.py
install_requires = [
'httplib2>=0.9.1',
'pyasn1>=0.1.7',
'pyasn1-modules>=0.0.5',
'rsa>=3.1.4',
'six>=1.6.1',
]
same applies to the other added recipes
I assume that you have ssh access to the device and your rootfs is
writeable - in that case you could use "devtool deploy-target".
Typical workflow would be something like this
- devtool modify python3
- devtool build python3
- devtool deploy-target -s python3 root@
if your rootfs is ramdisk
Hi Mikeal,
To me it seems like the makefile has no support for DESTDIR builtin -
which is the mechanism poky relies on.
I've seen this projects offers a cmake file as well, maybe you have more
luck with that, if not you have to patch the makefile.in, so it will
understand DESTDIR, which
I would say a `DEPENDS += "sed"` in the recipe should fix things - btw
sumo is kind of ancient already, ever considered updating to a newer
version of poky?
On 18.04.20 18:57, g...@missionsecure.com wrote:
I'm trying to create a recipe in Sumo for zeek (zeek.org) which uses
cmake. I'm
Hi,
I guess
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#new-recipe-post-installation-scripts
is what you looking for.
Best
Konrad
On 18.04.20 16:16, Rakesh Kumar wrote:
Hi all,
Can anyone give me any guidance in creating recipe for any application
which is
to
address such a problem, so take this reply as FYI.
Best
Konrad
On 03.04.20 21:28, Randy MacLeod wrote:
On 2020-04-02 4:44 a.m., Konrad Weihmann wrote:
To answer your others questions... see below
On 02.04.20 05:42, Randy MacLeod wrote:
On 2020-03-28 8:26 a.m., Konrad Weihmann wrote:
Hi
To answer your others questions... see below
On 02.04.20 05:42, Randy MacLeod wrote:
On 2020-03-28 8:26 a.m., Konrad Weihmann wrote:
Hi,
I'm facing the following error message sporadically on all branches I
tried so far (master, zeus, warrior and thud)
The stack trace of python calls
python cache files before
they are packaged - at least none of my recent build failed so far.
Any ideas how to tackle this problem, any suggestions?
Best
Konrad
On 02.04.20 05:42, Randy MacLeod wrote:
On 2020-03-28 8:26 a.m., Konrad Weihmann wrote:
Hi,
I'm facing the following error m
ng :) Effectively I was
attempting to duplicate get_out_dir() as found here:
https://github.com/flutter/engine/blob/master/tools/gn
My recipe is here:
https://github.com/jwinarske/meta-flutter/blob/zeus/recipes-graphics/flutter-engine/flutter-engine_git.bb
Cheers,
Joel
On Wed, Apr 1, 2020 at 10:4
There is a single tick missing, but I'm sure you get the point
On 01.04.20 19:37, Konrad Weihmann wrote:
What about
do_configure() {
cd ${@bb.utils.contains('PACKAGECONFIG_CONFARGS', '--verbose',
out/verbose', 'out', d)}
}
On 01.04.20 18:55, Joel Winarske wrote:
Hello,
I'm trying
What about
do_configure() {
cd ${@bb.utils.contains('PACKAGECONFIG_CONFARGS', '--verbose',
out/verbose', 'out', d)}
}
On 01.04.20 18:55, Joel Winarske wrote:
Hello,
I'm trying the below in a recipe. Bitbake gives me: ERROR: Unable to
parse ...: Exited with "2"
inherit python3native
anifest are not present in the
filesystem
On 28.03.20 13:26, Konrad Weihmann wrote:
Hi,
I'm facing the following error message sporadically on all branches I
tried so far (master, zeus, warrior and thud)
The stack trace of python calls that resulted in this
exception/failure was:
File: 'exec_python_func()
Hi Derek,
or maybe I'm mistaken about the layer priority and it's the order within
the bblayer.conf that does determine that (I tend to forget which one
applies to what stage).
Maybe you could try to move your layer to the end of the bblayer.conf
list (actually that was the case when I
What you could do is to override the file in a layer with higher priority.
Just create the same file under the same path (e.g.
/conf/machine/include/microblaze/feature-microblaze-versions.inc)
and apply the changes there - this should help for now.
But be aware that this way could lead to
AFAIK there is no way to mount something without root credentials.
fakeroot/pseudo is intercepting some calls before they will reach the
kernel, but mounting isn't a supported option - it just makes all child
processes think they running under uid 0.
What you could do is try to find an
ize is 3.9GB because of heavy size packages
required by my project and without project required packages my image
size in Yocto is 800MB.
I want to reduce the image size as maximum as possible.
Thanks a lot in advance,
Ajam Ali
---
Pretty general questions, but I try to answer your question.
I don't know what the purpose of your image is, but installing
development tools like boost-dev or gcc (I guess that is what you mean
with cpp) makes your image automatically a lot bigger, I would suggest
to put devtools into a
Hi,
I'm facing the following error message sporadically on all branches I
tried so far (master, zeus, warrior and thud)
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function:
0001:
***
Hi,
I'll get your point.
Maybe this could be a solution to your problem
https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#var-BBVERSIONS.
Instead of having different bbappends have one and pick the right steps
inside of the append.
If that is not working
Hi all,
it maybe a already solved, very trivial thing to do, but is there any
way in bitbake to prevent that a tool from the build host is executed
instead of the same tool (maybe) available via the sysroot-native?
In shell I would typically do (e.g.) something like this
python() { echo
-devel/2020-January/204363.html
so we won't be staying on 10.x, but if 12.x isn't enough to build without
meta-python2, then we might need 13.x :/.
On Tue, Jan 21, 2020 at 6:09 PM Konrad Weihmann
mailto:kweihm...@outlook.com>> wrote:
On 20.01.20 12:22, Ross Burton wrote:
> npm needing Py
On 20.01.20 12:22, Ross Burton wrote:
> npm needing Py2 is just disappointing. Surely someone has ported it
> to py3 by now?
>
Any news on that? From what I see nodejs is fully supporting python3 on
build host, only in 13.x branch (in 11.x and 12.x it's marked
'experimental', whatever that
Hi All,
I'm experiencing a strange issue when using thud branch with the
following recipe snippet
> SRC_URI = "git://github.com/pkg/diff;protocol=https"
on thud I get the following error
> 2019-12-27T19:31:21.3160449Z NOTE: recipe
github.com-pkg-diff-native-20190930-r0: task do_patch:
[mailto:yann.dir...@blade-group.com]
Gesendet: Mittwoch, 18. Dezember 2019 22:59
An: Konrad Weihmann
Cc: yocto@lists.yoctoproject.org
Betreff: Re: [yocto] Inverse of BBFILES_DYNAMIC
Le mer. 18 déc. 2019 à 21:10, Konrad Weihmann
mailto:kweihm...@outlook.com>> a écrit :
Hi All,
I was won
Hi All,
I was wondering if there is already a mechanism which kind of mimics the
inverse of BBFILES_DYNAMIC.
Like I want a recipe to be put into tree only if a layer is absent.
Example: I need a fancy python-lib, which isn't part of the core-lib, but
according to the layer index can be
61 matches
Mail list logo
