Minvera has quit [Remote host closed the connection]
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
thomasd13 has joined #yocto
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
BoJalling has quit [Ping timeout: 255 seconds]
BoJalling has joined #yocto
amitk has quit [Ping timeout: 255 seconds]
amitk has joined #yocto
rob_w has joined #yocto
BoJalling has quit [Ping timeout: 246 seconds]
BoJalling has joined #yocto
alessioigor has joined #yocto
<ArgaKhan>
Hello, I get the error; linux-dummy-dev : Depends: linux-dummy (= 1.0-r1) but it is not installable. I am using Kirkstone version and I added ALLOW_EMPTY:${PN} = "1" in poky/meta/recipes-kernel/linux/linux-dummy.bb but the problem persists.
<fmartinsons[m]>
Hello is anyone here using codium (https://vscodium.com/) for development, if so, did you know an extension for syntax highligh of yocto recipes and classes ?
invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
leon-anavi has joined #yocto
ptsneves has joined #yocto
BoJalling has quit [Ping timeout: 250 seconds]
BoJalling has joined #yocto
Guest6 has joined #yocto
<Guest6>
Does bitbake git fetch considers .gitconfig for url?
d-s-e has joined #yocto
Peter[m]12 has joined #yocto
goliath has joined #yocto
Bardon has joined #yocto
d-s-e has quit [Ping timeout: 260 seconds]
tunahan has quit [Quit: tunahan]
tunahan has joined #yocto
davidinux has quit [Ping timeout: 246 seconds]
davidinux has joined #yocto
Guest4467 has joined #yocto
<Guest4467>
Hi, why is qt so popular in embedded linux and why can't flutter be the replacement considering it is license free?
<Guest4467>
Is it about interfacing with hardware (i2c, spi etc.) that qt provides out-of-the-box experience?
<rburton>
Nothing stopping you using flutter? Qt has paid support, which many companies like.
<LetoThe2nd>
Guest4467: well flutter sees interest there and is used for things. if it matches your needs, go use it.
<LetoThe2nd>
and i've never heard about qt having out of the box spi support, but that would be kinda "neat" ;-)
d-s-e has joined #yocto
<LetoThe2nd>
Guest4467: oh and for the record, flutter is a) definitively not "license free", it is "bsd" which is clearly defined and b) it involves quite a bit of magic that is tied to Google. Not everybody likes that.
<neverpanic>
flutter is, in typical Google manner, ridiculously hard to compile from source with a ton of dependencies. Qt isn't.
<tunahan>
Hello, can someone help, I haven't been able to solve it for about 1 month. I get the error "linux-dummy-dev : Depends: linux-dummy (= 1.0-r1) but it is not installable". I am using the "Kirkstone" version and added "ALLOW_EMPTY:${PN} = "1"" in "poky/meta/recipes-kernel/linux/linux-dummy.bb" but the problem persists. "dev-pkgs" is turned on in "EXTRA_IMAGE_FEATURES". Link to my log file: https://paste.ee/p/qPzy6
<LetoThe2nd>
neverpanic: thats what i, more elegantly called "magic" ;-)
me57 has joined #yocto
<neverpanic>
My hardware token's GUI app to display TOTP codes has recently moved from Qt to flutter, I had a look at what it would take to package it, and I'm staying with the old Qt copy for now.
<mario-goulart>
Also, flutter is relatively recent. A lot of projects might even predate it.
<LetoThe2nd>
having said that, there seem to be people happy with using flutter in embedded. :-)
<qschulz>
Guest4467: some people are using LVGL BTW if you're looking for other techs too
<LetoThe2nd>
e.g. use what ever matches your usecase.
d-s-e has quit [Ping timeout: 250 seconds]
<me57>
Hello, all. I have a question on how to proceed creating a (python) virtual environment (venv) for the target using a (host) yocto recipe. How should I proceed ? Could anyone give me some pointer(s), please. I am relatively new to Yocto.
<me57>
(I hope I am in the correct chat channel, to start with)
<LetoThe2nd>
me57: you're in the right channel, but not sure everybody understands the question. your recipe, -native host only requires being run in a venv? (please not that I'm not a python guy, just trying to help and clarify).
BoJalling has quit [Ping timeout: 246 seconds]
<LetoThe2nd>
me57: and if so, why would that be? yocto treats all recipes as separate sysroots anyways.
BoJalling has joined #yocto
<Guest4467>
Is there a GUI tool that uses only Rust?
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
<me57>
a python venv is basically an environment in which some python script is running; the venv provides the needed imported modules on the running computer (in this case, the target) without so-to-say "polluting" the rest of the (target) environment.
<Guest4467>
The reason why I mentioned Flutter is that it doesn't seem to have libraries such as Qt that interact well with hardware protocols such as CAN, I2C etc. Which is why I brought this topic up. Even though you can compile it perfectly, it uses Dart.
d-s-e has joined #yocto
davidinux has quit [Ping timeout: 276 seconds]
<me57>
So this venv has to be installed by some (target) program. Which, I am afraid, cannot be done on the host
<me57>
It could possibly be done on the target the first time the target system runs, but I don't think this is the better way...
davidinux has joined #yocto
<Guest4467>
qschulz Didn't heard of that one before, LVGL sounds interesting thanks! Just like with other tools in which Rust "can" be used, they have https://github.com/rafaelcaricio/lvgl-rs
<Guest4467>
KDAB stated Rust bindings isn't quite what Rust devs want (memory safety), they developed CXX-RUST for Qt. Is there something similar to LVGL?
xmn has quit [Ping timeout: 246 seconds]
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
rob_w has quit [Quit: Leaving]
Guest4467 has quit [Quit: Client closed]
camus has quit [Remote host closed the connection]
<me57>
LetoThe2nd so I don't know how to proceed. To learn : what do you mean by your statement "yocto treats all recipes as separate sysroots anyways" ? What does "treating a recipe as a sysroot" mean ?
<ptsneves>
Guest4467: Another thing is that qt has native libraries which might be important for low cost hardware. Flutter if i remember correctly is an interpreted language
<ptsneves>
me57: It measn that for the purposes of building the recipe a custom sysroot is created in the recipe workspace. It does not bring more nor less than what you specified is needed to build the recipe
Tyaku has joined #yocto
camus has joined #yocto
<polprog>
I have a recipe (.bb) that aims to add a file to ${sysconfdir}/dropbear/, but it does not appear in the final rootfs.. how do i go about troubleshooting it?
<me57>
ptsneves I think I understand this. So as I need 3 modules to be installed in the venv, I know I'll have to first make those modules. AFAIK, this can be done on the host using the yocto cross-toolchain. But the virtual environment is something that cannot run on the host (I think). I think it will have to run on the target. So, I have the problem
<me57>
that it is not present in my created filesystem for the target, but to be generated by the target ?
seninha has quit [Remote host closed the connection]
seninha has joined #yocto
d-s-e has joined #yocto
<polprog>
i found the issue, when i open a devshell for this recipe i get dropped into ${S} which is empty and the source file i need to copy is directly in ${S}/../
<polprog>
but adjusting ${S} = "${WORKDIR}" as per the wiki did not change ${S} in the devshell
<polprog>
what should i do to either make it place the source file into ${S} or make ${S} point where the srouce file is placed?
BoJalling has quit [Ping timeout: 276 seconds]
BoJalling has joined #yocto
azcraft has joined #yocto
<ptsneves>
me57: i am not familiar with venv, that you mention. It is not a yocto concept
<rburton>
polprog: can you share the recipe?
d-s-e has quit [Ping timeout: 256 seconds]
<polprog>
rburton: i got the recipe buildingwithout errors now but it still does not appear in the target rootfs. the recipe is here: http://0x0.st/H-1D.bb
<rburton>
yeah that's not right
<polprog>
i have IMAGE_INSTALL += " hostkey " in my layer.conf but it still does not create the file in the target rootfs
<rburton>
sure, because do_rootfs is a task that only runs if you're building a rootfs, and your recipe builds a package
<polprog>
should i use do_install then?
<rburton>
instead you should have a do_install() that basically does install -d ${D}${sysconfig}/dropbear ; install ${S}/dropbear... ${D}${sysconfdir}/dropbear
<rburton>
FILES isn't needed as the default contains sysconfdir
<rburton>
and just assign to SRC_URI
<rburton>
you can drop PR too whilst you're there
<me57>
ptsneves OK, no problem. I am only looking for the conceptual things to do. And cross-compiling, cross-linking and all the like are things that can be done on the host, for the target. And it can all be put "as-built-on-the-host" into the target filesystem.
<rburton>
me57: you can make a venv in a recipe (afaik)
<me57>
rburton Glad to hear ! Could you give me some links or pointer to doc on how to do this ?
<rburton>
me57: create a venv in a task, put it in a package
<rburton>
haven't tried, but can't see why it *wouldn't* work
<rburton>
it _is_ a terrible idea
<me57>
OK, that's the principle. Question is : how do I do this (i.e. create a venv in a task) ?
<rburton>
python3 -mvenv my-new-venv
<me57>
Why is it (a terrible idea) ?
<Ablu[m]>
How can I do a custom patching logic (cannot be a .patch, since it depends on build environment variables) in a way that if the task that does the patching changes, I force bitbake to do a fresh unpack before (so that the source is in a clean state and does not have my patch logic applied already). Does that even work with the dependency model? How is this handled for normal .patch files (I tried to check the code, but I was not able to find
<Ablu[m]>
anything specific to this)?
<rburton>
me57: it's a terrible idea because you throw away all the useful bits of yocto for actual products: source caches, reproducibility, licenses manifests, etc
azcraft has quit [Remote host closed the connection]
<me57>
would I (not sure if I am well enough a python guy to see what you mean) ?
<polprog>
rburton: can i have my local.conf in <mylayer>/conf/ ? (where the layer.conf is?) I dont want to have it in the build directory since xilinx tools nuke it often
<rburton>
polprog: sounds like you need to make a new distro config or an image recipe
<me57>
rburton Would you know of an example I could have a look at (on how to create a venv in a task) ? I haven't succeeded (yet) to find some, probably because I just don't google the correct terms for what I try to achieve) ?
<rburton>
not off hand
<me57>
rburton because if I execute your sample above ("python3 -mvenv my-new-venv"), this will run on the host, but I'm puzzled there, as the result is intended for the target ?
<rburton>
*all* commands when you're building a recipe run on the host
<me57>
yes, for sure !
<rburton>
if you desperately want to do it on the target, then have a script to run on the target. write a systemd first-boot unit to run it, or something.
<me57>
that's indeed what I was afraid for. I would've hoped there was a host-based way to do this ...
<polprog>
i have a feeling yocto is a nice (very complicated but nice) buildsystem but the way petalinux uses it is just plain stupid
<polprog>
ive added the IMAGE_INSTALL line to a (new) local.conf, lets see if it works
<Ablu[m]>
hm it looks like do_patch() {} also does not magic regarding forcing a fresh unpack. Probably it just checks whether stuff is already applied somehow? At least when I just overwrite do_patch() {} then my logic also executes again... So I guess I would have to find a way to put a template into SRC_URI and base the patching on that? 🤔
<rburton>
Ablu[m]: if a file in SRC_URI cahnges, unpack has to re-run
<rburton>
you should definitely put your "patch" in SRC_URI if its a file
<rburton>
then it gets cached, archived, tracked, etc
camus has quit [Quit: camus]
<Ablu[m]>
rburton: 👍️. Right. I realized that what I was trying would not work with caching in any way... I guess I could just put a shell script there and have that execute during build...
Tyaku has quit [Ping timeout: 264 seconds]
<mischief>
me57: why you need venv? why not normal python build/install etc?
<rburton>
the correct thing to do is absolulely to just write a recipe for the package
<rburton>
s
BoJalling has quit [Ping timeout: 250 seconds]
BoJalling has joined #yocto
GNUmoon has quit [Ping timeout: 255 seconds]
<me57>
@mis
Tyaku has quit [Quit: Lost terminal]
<me57>
mischief This is not up to me to decide. I've been said something like "this is not the pythonic way".
<rburton>
_every distro_ on the plane is arguing with python about what 'pythonic' means, because when you're building a distro (read: entire disk image from the kernel up) you don't care what the python-way is, because the pythonic way only applies to single applications
<rburton>
on the planet, obviously
<me57>
rburton I can follow you.
<me57>
I just can't be involved in some political discussions ...
d-s-e has joined #yocto
<ptsneves>
rburton: I think in this plane there is this discussion. I wonder what the shadow plane consensus on python is.
Schlumpf has quit [Quit: Client closed]
amitk has quit [Ping timeout: 250 seconds]
<me57>
rburton mischief OTOH, we are building a yocto image targeting an SBC on which we want the final (TBH : application-oriented) customisations using yocto. Maybe it's just tweaking yocto a little too much...
<mischief>
hey, we also build a yocto image targeting an SBC! what a coincidence :-)
<me57>
can't be. You're kidding
<mischief>
worst case you could tar up your program, extract it in a yocto recipe and be on your merry way
<mischief>
though that's a terrible idea
GNUmoon has joined #yocto
<me57>
In the meantime I have found pypi.bbclass . Seems to go in the direction I'm after.
AKN has joined #yocto
<qschulz>
me57: considering that Yocto only allows you to include **one** version of a package in your image, pyenv/venv is likely useless
<qschulz>
I'd use venv if I had to support multiple Python-based software stack not necessarily requiring the same dependencies or their versions
<qschulz>
but you're going to have a bad time using yocto for that anyways, venv is not going to help you do it properly i'm afraid
<qschulz>
(except if you download dependency with pip directly inside your recipe, but then youre just not going the Yocto way :) )
<me57>
qschulz The idea behind it would be that if we update the one python program, we don't have to tweak the complete system setup in such a case, just update the venv containing the python program
<rburton>
so fun for, ensurepip really doesn't like running inside a venv with our python. not sure what's going on there.
<rburton>
oh god my typing today
<rburton>
python being python means we have to beat it with a bit stick to be relocated, and i think the relocation is upsetting it
<me57>
rburton ... meaning the target venv creation would be the least error-prone way to create the venv, right ?
<me57>
(I mean, the venv creation ... on the target itself)
<rburton>
probably, albeit horrible
<rburton>
of course unless you've got 100 dependencies, you could have written the recipes for them already by now :)
kscherer has joined #yocto
<polprog>
rburton: it works now! Thank you very much :)
<rburton>
me57: so venvs need to be relocated as they contain a build-time path in, which is fun
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
<ptsneves>
If i wanted to find all providers that set a variable to a value, how would i do that from tinfoil?
<rburton>
ptsneves: see scripts/contrib/verify-homepage, athough that does a bit of extra work to filter out BBCLASSEXTENDs. you'll need to iterate all recipes.
<ptsneves>
rburton: interesting it iterates through the recipecaches. Any reason it is prefered to tinfoil.all_recipe_files?
azcraft has joined #yocto
<rburton>
ptsneves: honestly, that script probably predates all_recipe_files
<ptsneves>
rburton: ok because all_recipe_files even has a variants argument that excludes BBCLASSEXTENDs
<ptsneves>
good to know
<rburton>
yeah use that :)
<ptsneves>
tinfoil is amazing :)
sakoman has joined #yocto
BoJalling has quit [Ping timeout: 268 seconds]
BoJalling has joined #yocto
astlep5504 has joined #yocto
florian_kc has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
<tunahan>
Hello, can someone help, I haven't been able to solve it for about 1 month. I get the error "linux-dummy-dev : Depends: linux-dummy (= 1.0-r1) but it is not installable". I am using the "Kirkstone" version and added "ALLOW_EMPTY:${PN} = "1"" in "poky/meta/recipes-kernel/linux/linux-dummy.bb" but the problem persists. "dev-pkgs" is turned on in "EXTRA_IMAGE_FEATURES". Link to my log file: https://paste.ee/p/qPzy6
xmn has joined #yocto
<abelloni>
ALLOW_EMPTY:${PN}-dev = "1" ?
invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
AKN has quit [Read error: Connection reset by peer]
<tunahan>
That didn't work either. While trying your method, I saw another file named "openembedded-core/meta/recipes-kernel/linux/linux-dummy.bb" and I added "ALLOW_EMPTY:${PN} = "1"" in it. Problem solved, thank you for your help.
<rburton>
poky is a copy of oe-core, so you don't need both
<rburton>
they're the same file, and you were editing the wrong one
<tunahan>
Do I need to delete poky in this case?
me57 has quit [Ping timeout: 260 seconds]
BoJalling has quit [Ping timeout: 246 seconds]
BoJalling has joined #yocto
<qschulz>
tunahan: likely only one of the layers is used, check your conf/bblayers.conf in your build directory
<qschulz>
you should see either openembedded-core or poky in there
<qschulz>
remove the one that doesn't appear here
<tunahan>
qschulz: yes, there is no poky bblayers either. That little distraction cost me a month. So sad. But thanks for your help.
fabo has quit [Quit: Client closed]
seninha has quit [Quit: Leaving]
berton[m] has quit [Quit: You have been kicked for being idle]
BenkeHargitai[m] has quit [Quit: You have been kicked for being idle]
d-s-e has quit [Quit: Konversation terminated!]
BoJalling has quit [Ping timeout: 276 seconds]
BoJalling has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
rfuentess has quit [Remote host closed the connection]
vmeson has quit [Read error: Connection reset by peer]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
vvmeson has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
Guest6 has quit [Quit: Client closed]
goliath has quit [Quit: SIGSEGV]
Xagen has joined #yocto
florian_kc has quit [Ping timeout: 252 seconds]
|Xagen has quit [Ping timeout: 276 seconds]
florian has quit [Quit: Ex-Chat]
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
<fury>
i am having the issue described in this thread: https://lists.yoctoproject.org/g/yocto/topic/95170677#58598 - but i can't use master because "ERROR: Layer raspberrypi is not compatible with the core layer which only supports these series: mickledore (layer is compatible with kirkstone)"
<fury>
any ideas on how to fix?
<rburton>
use meta-raspberrypi master and not kirkstone
<rburton>
you need to match the layer branches
<rburton>
of course using master is for the brave and/or foolish, as its not a release
<fury>
oof... guess i'm out of luck, i don't think there's a qt layer that is compatible with anything newer than kirkstone
<rburton>
meta-qt5? that supports mickledore too.
<fury>
i am trying to build boot2qt for qt 6.4.3 and running into all sorts of weird issues, this was one of them
<fury>
and that's the latest i can find
<fury>
it's all set up for kirkstone
<rburton>
fury: try using the 64-bit raspberrypi machines
<rburton>
i _think_ that bug in the rust code is an omission for the 32-bit platforms
<fury>
i need to build for pi 0 w unfortunately :(
<fury>
and i also had to downgrade libvpx because newer versions of that dropped support for armv6 lol
<rburton>
i guess upgrading to the pi0 2 is not an option
<fury>
not until i can get my hands on one (or two)
<fury>
i am signed up for stock alerts
* fury
crosses fingers
* rburton
fires off a kirkstone build to see if he can replicate the rust thing
<tangofoxtrot>
I have a project that is still stuck on thud. :(
goliath has quit [Quit: SIGSEGV]
mvlad has quit [Quit: Leaving]
<JaMa>
tangofoxtrot: what it is?
<tangofoxtrot>
customer project. No changes allowed.
<JaMa>
I wanted to know which projects to avoid :)
<JaMa>
or consumer products if it's used in some
<tangofoxtrot>
hah... NDA. Doubt you will ever see one, so you're safe.
<sudip>
tangofoxtrot: you are lucky, one of mine is at Krogoth :(
<tangofoxtrot>
Nice! :D Another project was at Jethro - they are upgrading to Dunfell. So.. progress!
azcraft has quit [Remote host closed the connection]
azcraft has joined #yocto
<moto-timo>
Not that long ago someone said they were "stuck on daisy".
<moto-timo>
Other than medical devices, radio frequency compliance, FIPS... etc. (expensive validation testing) there are very few valid reasons to stay on old Yocto Project releases.
<moto-timo>
s/validation/compliance/
<tangofoxtrot>
No argument from me.
<moto-timo>
Now, getting silicon vendors to continue supporting older SOCs/SOMs... even when you hand them the upgrade... that's a different story