Re: [yocto] how to add tkinter in Yocto?
On 11/4/23 16:55, shrikantvaish...@hotmail.com wrote: /ERROR: Nothing PROVIDES 'tk' (but /home/shri/Yocto_Rasp/poky/meta/recipes-devtools/python/python3_3.11.2.bb DEPENDS on or otherwise requires it). Close matches:/ / atk/ /NOTE: Runtime target 'python3-tkinter' is unbuildable, removing.../ /Missing or unbuildable dependency chain was: ['python3-tkinter', 'tk']/ tk is part of meta-oe - have you added its folder to BBLAYERS in bblayers.conf? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61615): https://lists.yoctoproject.org/g/yocto/message/61615 Mute This Topic: https://lists.yoctoproject.org/mt/102385809/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] how to add tkinter in Yocto?
Hello all, I want to add " *Tkinter"* in my Linux image and for this, i have added these two line in my local.conf file. * (1)" IMAGE_INSTALL:append = " python3-tkinter" (2)PACKAGECONFIG:append:pn-python3 = " tk" * When I compile i get the following errors: * shri@Shri:~/Yocto_Rasp/poky$ bitbake core-image-sato Loading cache: 100% |#| Time: 0:00:00 Loaded 1838 entries from dependency cache. NOTE: Resolving any missing task queue dependencies ERROR: Nothing PROVIDES 'tk' (but /home/shri/Yocto_Rasp/poky/meta/recipes-devtools/python/python3_3.11.2.bb DEPENDS on or otherwise requires it). Close matches: atk NOTE: Runtime target 'python3-tkinter' is unbuildable, removing... Missing or unbuildable dependency chain was: ['python3-tkinter', 'tk'] ERROR: Required build target 'core-image-sato' has no buildable providers. Missing or unbuildable dependency chain was: ['core-image-sato', 'python3-tkinter', 'tk'] * What am I doing wrong? * * Please help after this I also want to add *" ttkbootstrap/custom-tkinter "* for a modern UI look and feel. * Thanks and Regards Shrikant Vaishnav * -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61614): https://lists.yoctoproject.org/g/yocto/message/61614 Mute This Topic: https://lists.yoctoproject.org/mt/102385809/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Missing -lgpiod during linking an application that uses libgpiod
I solved the issue. It turned out to be not a yocto but a Qt problem. The Makefile used to build the application is autogenerated by qmake so you have to include LIBS += -lgpiod in order to add the library in the linking stage. I was looking in the wrong place! Sorry for the noise javi -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61613): https://lists.yoctoproject.org/g/yocto/message/61613 Mute This Topic: https://lists.yoctoproject.org/mt/102383036/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] Missing -lgpiod during linking an application that uses libgpiod
Hi,
I’m building a Qt application to controls a few GPIOs so, in my recipe, I add
libgpiod to the DEPENDS variable, but even then the –lgpiod is missing in the
linking stage and the build fails with several ‘undefined reference’ errors to
the gpiod functions:
|
/build/tmp/work/cortexa53-crypto-imx-ked-linux/testapp/0.1-r0/recipe-sysroot-native/usr/bin/aarch64-ked-linux/../../libexec/aarch64-ked-linux/gcc/aarch64-ked-linux/11.4.0/ld:
/usr/src/debug/ testapp /0.1-r0/build/../m4/inou.c:48: undefined reference to
`gpiod_chip_get_line'
| /build/tmp/work/cortexa53-crypto-imx-ked-linux/ testapp
/0.1-r0/recipe-sysroot-native/usr/bin/aarch64-ked-linux/../../libexec/aarch64-ked-linux/gcc/aarch64-ked-linux/11.4.0/ld:
/usr/src/debug/ testapp /0.1-r0/build/../m4/inou.c:55: undefined reference to
`gpiod_line_request_output'
| /build/tmp/work/cortexa53-crypto-imx-ked-linux/ testapp
/0.1-r0/recipe-sysroot-native/usr/bin/aarch64-ked-linux/../../libexec/aarch64-ked-linux/gcc/aarch64-ked-linux/11.4.0/ld:
/usr/src/debug/ testapp /0.1-r0/build/../m4/inou.c:61: undefined reference to
`gpiod_line_set_value'
| /build/tmp/work/cortexa53-crypto-imx-ked-linux/ testapp
/0.1-r0/recipe-sysroot-native/usr/bin/aarch64-ked-linux/../../libexec/aarch64-ked-linux/gcc/aarch64-ked-linux/11.4.0/ld:
/usr/src/debug/ testapp /0.1-r0/build/../m4/inou.c:67: undefined reference to
`gpiod_line_release'
| /build/tmp/work/cortexa53-crypto-imx-ked-linux/ testapp
/0.1-r0/recipe-sysroot-native/usr/bin/aarch64-ked-linux/../../libexec/aarch64-ked-linux/gcc/aarch64-ked-linux/11.4.0/ld:
/usr/src/debug/ testapp /0.1-r0/build/../m4/inou.c:69: undefined reference to
`gpiod_chip_close'
This is my recipe:
SUMMARY = "GPIO QT TEST APPLICATION"
DESCRIPTION = "GPIO user interface build with QT"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "
file://${COREBASE}/meta/files/common-licenses/GPL-2.0-only;md5=801f80980d171dd6425610833a22dbe6
(
file://$%7bCOREBASE%7d/meta/files/common-licenses/GPL-2.0-only;md5=801f80980d171dd6425610833a22dbe6
) "
SRC_URI = ""
DEPENDS += "qtbase qtdeclarative qtmultimedia qtwebengine *libgpiod* "
RDEPENDS:${PN} += "qtxmlpatterns qtdeclarative-qmlplugins qtbase-plugins
ttf-dejavu-sans qtquickcontrols qtquickcontrols2 qtfreevirtualkeyboard "
S = "${WORKDIR}"
do_install:append () {
install -d ${D}${bindir}
install -m 0775 qt_testgpio ${D}${bindir}
}
FILES:${PN} += "${bindir}/qt_testgpio"
FILES:${PN} += "/opt/*"
inherit qmake5
What am I missing? Shouldn’t the inclusion of libpgiod library to the DEPENDS
variable result in the addition of –lgpiod to the link command? I tried to add
LDFLAGS:append = “ –lgpiod” but it didn’t solve the problem.
Any help will be appreciated.
Kind regards,
Javi
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61612): https://lists.yoctoproject.org/g/yocto/message/61612
Mute This Topic: https://lists.yoctoproject.org/mt/102383036/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [OE-core] Core workflow: sstate for all, bblock/bbunlock, tools for why is sstate not being reused?
On Sat, 2023-11-04 at 11:29 +0100, adrian.freiho...@gmail.com wrote:
> Hi Alex, hi Richard
>
> After some internal discussions, I would like to clarify my previous
> answers on this topic.
>
> * Usually there are two different workflows
> - application developers: could use an SDK with a locked sstate-cache.
> - Yocto/BSP developers: need an unlocked SDK. They change the recipes.
> * A locked SDK
> - can work with setscene from SSTATE_MIRRORS
> - setscene does caching in the SSTATE_DIR (no issue about that)
> - But network problems can occur during the initial build because
> bitbake executes many independent setscene tasks. Opening so many
> independent connections slows down the build, especially if the
> server treats them as a denial of service attack.
> - The denial of service problem is difficult to solve because each
> setscene task runs in its own bibtake task. Reusing a connection to
> download multiple sstate artifacts seems almost impossible.
> This is much easier to solve with separate sstate download script.
FWIW, we did have a similar issue with do_fetch overloading
servers/proxies/ISPs and added:
do_fetch[number_threads] = "4"
Finding the right place to put a thread limit on overall setscene tasks
is harder but in theory possible. Or perhaps a "network capable tasks"
thread limit?
Is the overload caused by the initial query of sstate presence, or,
does it happen when the setscene tasks themselves run?
> * An unlocked SDK
> - Tries to download the sstate cache for changed recipes and their
> dependencies, which obviously can't work.
> - The useless download requests slow down the build considerably and
> cause a high load on the servers without any benefit.
Is this sstate over http(s) or something else? I seem to remember you
mentioning sftp. If this were using sftp, it would be horribly slow as
it was designed for a light overhead "does this exist?" check which
http(s) can manage well.
Recently we've been wondering about teaching the hashequiv server about
"presence", which would then mean the build would only query things
that stood a good chance of existing.
> - A script which gets a list of sstate artifacts from bitbake and then
> does a upfront download works much better
>+ The script runs only when the user calls it or the SDK gets boot-
> strapped
>+ The script uses a reasonable amount of parallel connections which
> are re-used for more then one artifact download
Explaining to users they need to do X before Y quickly gets tiring,
both for people explaining it and the people doing it trying to
remember. I'd really like to get to a point where the system "does the
right thing" if we can.
I don't believe the problems you describe are insurmountable. If you
are using sftp, that is going to be a big chunk of the problem as the
system assumes something faster is available. Yes, I've taken patches
to make sftp work but it isn't recommended at all. I appreciate there
would be reasons why you use sftp but if it is possible to get a list
of "available sstate" via other means, it would improve things.
> * Idea for a smart lock/unlock implementation
> - Form a user's perspective a locked vs. an unlocked SDK does not make
> much sense. It makes more sense if the SDK would automatically
> download the sstate-cache if it is expected to be available.
> Lets think about an implementation (which allows to override the
> logic) to switch from automatic to manual mode:
>
> SSTATE_MIRRORS_ENABLED ?= "${is_sstate_mirror_available()}"
What determines this availability? I worry that is something very
fragile and specific to your use case. It is also not an all or nothing
binary thing.
> In our case the sstate mirror is expected to provide all artifacts
> for tagged commits and for some git branches of the layer
> repositories.
> The sstate is obviousely not usable for a "dirty" git layer
> repository.
That isn't correct and isn't going to work. If I make a single change
locally, there is a good chance that 99.9% of the sstate could still be
valid in some cases. Forcing the user through 10 hours of rebuild when
potentially that much was available is a really really bad user
experience.
> That's what the is_sstate_mirror_available function
> could check to automatically enable and disable lazy downloads.
>
> - If is_sstate_mirror_available() returns false, it should still be
> possible to initiate a sstate-cache download manually.
>
> * Terminology
> - Older Yocto Releases:
>+ eSDK means an installer which provides a different environment with
> different tools
>+ The eSDK was static, with a locked sstate cache
>+ Was for one MACHINE, for one image...
> - Newer Yocto Releases:
>+ The bitbake environment offers all
Re: [yocto] [OE-core] Core workflow: sstate for all, bblock/bbunlock, tools for why is sstate not being reused?
Hi Alex, hi Richard
After some internal discussions, I would like to clarify my previous
answers on this topic.
* Usually there are two different workflows
- application developers: could use an SDK with a locked sstate-cache.
- Yocto/BSP developers: need an unlocked SDK. They change the recipes.
* A locked SDK
- can work with setscene from SSTATE_MIRRORS
- setscene does caching in the SSTATE_DIR (no issue about that)
- But network problems can occur during the initial build because
bitbake executes many independent setscene tasks. Opening so many
independent connections slows down the build, especially if the
server treats them as a denial of service attack.
- The denial of service problem is difficult to solve because each
setscene task runs in its own bibtake task. Reusing a connection to
download multiple sstate artifacts seems almost impossible.
This is much easier to solve with separate sstate download script.
* An unlocked SDK
- Tries to download the sstate cache for changed recipes and their
dependencies, which obviously can't work.
- The useless download requests slow down the build considerably and
cause a high load on the servers without any benefit.
- A script which gets a list of sstate artifacts from bitbake and then
does a upfront download works much better
+ The script runs only when the user calls it or the SDK gets boot-
strapped
+ The script uses a reasonable amount of parallel connections which
are re-used for more then one artifact download
* Idea for a smart lock/unlock implementation
- Form a user's perspective a locked vs. an unlocked SDK does not make
much sense. It makes more sense if the SDK would automatically
download the sstate-cache if it is expected to be available.
Lets think about an implementation (which allows to override the
logic) to switch from automatic to manual mode:
SSTATE_MIRRORS_ENABLED ?= "${is_sstate_mirror_available()}"
In our case the sstate mirror is expected to provide all artifacts
for tagged commits and for some git branches of the layer
repositories.
The sstate is obviousely not usable for a "dirty" git layer
repository. That's what the is_sstate_mirror_available function
could check to automatically enable and disable lazy downloads.
- If is_sstate_mirror_available() returns false, it should still be
possible to initiate a sstate-cache download manually.
* Terminology
- Older Yocto Releases:
+ eSDK means an installer which provides a different environment with
different tools
+ The eSDK was static, with a locked sstate cache
+ Was for one MACHINE, for one image...
- Newer Yocto Releases:
+ The bitbake environment offers all features of the eSDK installer. I
consider this as already implemented with meta-ide-support and
build-sysroots.
+ The term eSDK means a replicable bitbake environment. (The
documentation was recently changed in that sense)
+ The new SDK installer can be generated in different variants similar
to what was already supported by the eSDK
installer: https://docs.yoctoproject.org/sdk-manual/appendix-
customizing.html#customizing-the-extensible-sdk-standalone-
installer.
* The lightest variant is just a script that sets up the layers (git
clone or git checkout) and provides the build config. If
SSTATE_MIRRORS are configured lazy downloads will just work
otherwise bitbake will compile everything from scratch.
* The heaviest variant of the SDK installer includes the layers and
the sstate-cache. After installing it is_sstate_mirror_available()
evaluates to True.
* devtool ide
- Tries to bring this ideas further towards IDE configuration
- It supports two modes: No recipe mode is like the old eSDK
environment. The recipe mode goes beyond that. It is based on
devtool modify.
- Naming: I was thinking about "devtool ide" versus "devtool esdk"
+ Why ide? I want to set up my IDE to work with the Yocto SDK. And
that means, of course, that I have to bootstrap the SDK.
+ Could also be esdk: I want to bootstrap the eSDK and that should
also configure my IDE.
* Latest patch series is here:
- https://lists.openembedded.org/g/openembedded-core/message/189899
- docs: https://lists.yoctoproject.org/g/docs/message/4578
Adrian
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61610): https://lists.yoctoproject.org/g/yocto/message/61610
Mute This Topic: https://lists.yoctoproject.org/mt/102320109/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
