camus has quit [Remote host closed the connection]
camus has joined #yocto
Guest9146 has quit [Quit: late]
zpfvo has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 255 seconds]
camus1 is now known as camus
yocton_ is now known as yocton
zpfvo has quit [Quit: Leaving.]
zpfvo has joined #yocto
camus has quit [Remote host closed the connection]
camus has joined #yocto
FredericOuellet[ has quit [Quit: You have been kicked for being idle]
florian has joined #yocto
<qschulz>
Happy New Year every one, wishing you health and successful hacking this year
florian has quit [Ping timeout: 252 seconds]
d-s-e has joined #yocto
d-s-e has quit [Ping timeout: 252 seconds]
dmoseley has joined #yocto
dmoseley has quit [Ping timeout: 260 seconds]
d-s-e has joined #yocto
florian has joined #yocto
florian has quit [Ping timeout: 264 seconds]
mckoan|away is now known as mckoan
zpfvo has quit [Ping timeout: 268 seconds]
<mckoan>
Happy 2023 qschulz, everyone
zpfvo has joined #yocto
yann has quit [Remote host closed the connection]
Payam has joined #yocto
<michaelo>
Thanks qschulz! May your wishes come true for all of us :)
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
seninha has joined #yocto
zpfvo has quit [Ping timeout: 248 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
dmoseley has joined #yocto
Payam has quit [Quit: Leaving]
camus has quit [Remote host closed the connection]
camus has joined #yocto
yann has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
otavio has quit [Remote host closed the connection]
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
azcraft has joined #yocto
otavio has joined #yocto
nemik has quit [Ping timeout: 255 seconds]
florian has joined #yocto
nemik has joined #yocto
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #yocto
money has joined #yocto
money is now known as Guest2773
d-s-e has quit [Ping timeout: 264 seconds]
Guest2773 has quit [Quit: late]
mckoan is now known as mckoan|away
tunahan has joined #yocto
<tunahan>
Hello, I want to install the available debian deb packages on Yocto. How can I do that? I've created recipes for it, but I'm getting this error: "Nothing RPROVIDES 'libcurl3-gnutls_7.74'"
<qschulz>
tunahan: you probably shouldn't install a debian package on Yocto
<qschulz>
it's very likely the dependencies will be in completely different versions
<qschulz>
in yocto than what is used in debian
<tunahan>
qschulz: but there are versions that the software we use is obligatory. Actually, after compiling yocto, I can install the same dep files with the "dpkg -i" command, but I want it to be installed during the construction phase and not interfere with the system after installation.
<tunahan>
qschulz: Please tell me if I didn't explain properly, maybe my English is not good enough. I will try to explain again.
<qschulz>
tunahan: how this is usually done is to send a Yocto SDK of your image to your software provider and ask them to rebuild the binary with it, then you add the binary in your layer
<qschulz>
tunahan: fundamentally what you're trying to do is install a Debian package on a Fedora distribution
<qschulz>
(Fedora being your Yocto distribution, it's just something to make it easier to understand)
<qschulz>
could it work? yes. Should you? mmm no :)
<tunahan>
qschulz: actually we are also the software producer :D That unit didn't want to do that job just because of the workload. so I wanted to follow an alternative method. If this alternative method cannot be done, I can force the relevant unit for compatibility :D
<qschulz>
tunahan: ok then create a recipe from the source code and build within Yocto directly
<qschulz>
more effort first, but MUCH better
<qschulz>
if you have access to the debian package source code, you can figure out how they are building it and create the recipe yourself
<qschulz>
for some very big projects, it might take a few additional recipes to be created first
<qschulz>
i hope it's not some python/javascript/node/go/rust project because this can requires a lot of non-trivial recipes to be created
<tunahan>
this is also a limitation, because I couldn't find the source code of several packages like java and it doesn't exist. I was wondering if I could do the work I did with "dpkg -i" on the embedded system after the build, during bitbake. but i guess that is not possible. I will build first and then I will ask them to compile again on the embedded system, right?
<qschulz>
tunahan: no, ask them for the sources and how they are building it, which dependencies it requires and add them to your layer
<qschulz>
because the next time you upgrade your layers, you'll have to have them build on the target again (or via the SDK)
<qschulz>
the SDK is the lesser evil short term, but I would really recommend building from sources directly in yocto
<qschulz>
(-c populate_sdk is what you're after to create an SDK)
<qschulz>
(see docs also on how to do it, don't have a link at hand but shouldn't be too hard to find it on docs.yoctoproject.org)
<tunahan>
qschulz: If you're telling me to get it from my team, the source code is like this, a code written in qt5. How can I add the source code for this?
<qschulz>
tunahan: you need to create a recipe for it in your layer
<qschulz>
also you'll very liklely need to add meta-qt5 layer to your yocto setup
bps has joined #yocto
bps has quit [Changing host]
bps has joined #yocto
<tunahan>
qschulz: Well, I want to ask one more question. For example, the software compiled by our team in QT5 is dependent on libcrypto1.1, but I cannot build Yocto with the libcrypto1.1 library. It is based on libcrypto3.0. how do i solve this?
<qschulz>
tunahan: you ask your team to move to openssl3
<qschulz>
(this is not entirely a joke, since openssl 1.1.1 is EOL in October 2023)
<tunahan>
qschulz: Yes we tried this but QT5 depends on openssl1.1 and does not recognize openssl3. QT6 recognizes openssl3, but switching to QT6 causes a lot of corruption in the code.
<qschulz>
tunahan: check how meta-qt5 is handling this
<qschulz>
tunahan: I assume it might just work with openssl3?
<qschulz>
(if you don't do crazy stuff outside of qt5?)
florian_kc has joined #yocto
<qschulz>
meta-qt5 seems to enable openssl3 by default in the master branch
<tunahan>
qschulz: Then I'll have to try and see as you said. Now I have to find a way to bitbake that huge QT5-written source code.
<qschulz>
tunahan: look at other qt recipes
<qschulz>
I think you mainly need to inherit qmake first
<qschulz>
inherit qmake5 and probably pkgconfig too
florian has quit [Ping timeout: 252 seconds]
<tunahan>
qschulz: Ok. I'm going on a big journey now. Let's see where it will end. I hope it turns out as we think. Thanks everything.
<qschulz>
tunahan: good luck, come back to tell us how it's going :)
<qschulz>
(also if you're creating a new layer/product, please use something supported, like Dunfell, Kirkstone or Langdale (preference on the first two since they are supported for longer))
manuel1985 has joined #yocto
<tunahan>
qschulz: I use Kirkstone. It will probably go the longest.
d-s-e has joined #yocto
azcraft has quit [Ping timeout: 255 seconds]
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
d-s-e has quit [Ping timeout: 268 seconds]
<kanavin>
qschulz, if someone is creating a new layer or product, the preference should be on following master
<kanavin>
settling on a LTS branch is counter-productive in the long term
manuel1985 has quit [Ping timeout: 265 seconds]
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
d-s-e has joined #yocto
azcraft has joined #yocto
_azcraft has joined #yocto
azcraft has quit [Read error: Connection reset by peer]
d-s-e has quit [Ping timeout: 256 seconds]
gsalazar has joined #yocto
d-s-e has joined #yocto
d-s-e has quit [Client Quit]
sakoman has joined #yocto
camus has quit [Remote host closed the connection]
camus has joined #yocto
manuel1985 has joined #yocto
thomasd13 has quit [Ping timeout: 265 seconds]
<qschulz>
kanavin: depends on your time to market, also starting on master when you're starting with Yocto might not be the easiest since you might have to debug things in recipes/core. but otherwise agree yes :)
<kanavin>
qschulz, the market will eventually ask for a software update for your product :)
<kanavin>
and things are heading towards legislation for that too
<qschulz>
kanavin: what happens if you want to release before current master gets a release?
<qschulz>
basing on master makes sense if we're talking about months/years of work. otherwise, LTS is fine. But also.. I'm taking care of very small BSP layers, so not much to do for me :)
<kanavin>
qschulz, you then base at the bifurcation point of master and latest stable release
<kanavin>
that's what i do when customers ask for e.g. 'kirkstone'
<kanavin>
I do not give them latest kirkstone, I give them kirkstone when it was pointing to the same commit as master, for the last time
<kanavin>
then they can take both paths if they so wish
<qschulz>
kanavin: meh, this offsets some work and decision to the client. And sometimes they just take whatever you give them without thinking too much
<qschulz>
c.f. the so many "oh but my vendor only gives me X version of Yocto"
<qschulz>
and there, by giving them pre-kirkstone-4.0 you basically provide them with a product stack that is basically already vulnerable to security issues that are already fixed
<qschulz>
I guess it depends where you decide to draw the line between your work as a software provider and where the client needs to start working on stuff
<kanavin>
qschulz, they would have to update to latest LTS anyway on a regular basis. Giving them a stack that can be taken in both directions is in the long term interests of any vendor. Even if they do not know it yet.
<kanavin>
(both directions means one branch for LTS point releases, another for master milestones)
<qschulz>
kanavin: yeah, ideally you should always have a latest release and master branches for your software and fix bugs as they come
<kanavin>
what you suggest on the other hand, perpetuates this awful situation where someone is stuck on an ancient yocto, and can't benefit from latest developments and security
<qschulz>
don't have a real need for BSP layers (maybe I'm mistaken), and don't have the bandwidth to handle all of this myself though. But best practice, for sure :)
<kanavin>
even if *right now* it is still in the LTS window
<qschulz>
kanavin: yeah, I get that. Difficult for me to recommend starting on "untested" master branch for someone who starts with Yocto
<kanavin>
qschulz, I think base release tags are the bifurcation point, so it's quite tested by then