<yates_work>
i can build the static qtbase libraries via "bitbake qtbase-staticdev", however how do i get my own qt app recipe to build them? using "DEPENDS = "qtbase-staticdev" doesn't work.
<yates_work>
neither does specifying a .pro file that has "CONFIG += static"
<zhmylove>
yates_work: what do you mean under "own recipe to build them"?
<zhmylove>
BTW qtbase-staticdev is a name of a package, not a recipe. You cannot DEPEND on it
<zhmylove>
In case you need some statically built libraries before compilation of your recipe, you can DEPEND on qtbase and hope that do_populate_sysroot will give you static libs. If not, then just create a bbappend on it to explicitly add them for populate_sysroot via a variable
tangofoxtrot has quit [Remote host closed the connection]
tangofoxtrot has joined #yocto
zhmylove has quit [Remote host closed the connection]
brazuca has quit [Quit: Client closed]
goliath has quit [Quit: SIGSEGV]
davidinux has quit [Ping timeout: 260 seconds]
davidinux has joined #yocto
luneff has quit [Ping timeout: 240 seconds]
luneff has joined #yocto
vladest has quit [Remote host closed the connection]
<PhoenixMage>
Quick question, is "part --offset" absolute or relative to the last partition? Reading the wic docs it sounds to me like its absolute but reading the wic file and looking at the partition table on disk each partition offset looks relative to the end of the last?
<PhoenixMage>
Hey LetoThe2nd appreciate your response on Mender hub
<PhoenixMage>
Ignore my question, forgot to take something into account
luneff has quit [Ping timeout: 258 seconds]
<LetoThe2nd>
PhoenixMage: sure thing!
arob109 has quit [Ping timeout: 240 seconds]
alessioigor has joined #yocto
Vonter has quit [Ping timeout: 240 seconds]
Vonter has joined #yocto
mvlad has joined #yocto
lighteagle has quit [Ping timeout: 258 seconds]
linfax has joined #yocto
rob_w has joined #yocto
<LetoThe2nd>
yo dudX
Ram94 has joined #yocto
linfax has quit [Quit: Leaving]
<alessioigor>
good morning
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
linfax has joined #yocto
warthog9 has quit [Remote host closed the connection]
mckoan|away is now known as mckoan
<mckoan>
good morning
Notgnoshi has quit [Remote host closed the connection]
<KanjiMonster>
if you go through each releases' migration notes it should give you a good idea what you need to change
<varjag>
thanks a lot
<varjag>
we're jumping over a few yes
<rob_w>
what would be best practice if i want to use the same toolchain for 2 MACHINES but they are very similar , like am335x & am437x ? is that possible ?
Daanct12 has quit [Quit: WeeChat 4.0.4]
<Tom25>
Hello! I'm currently try to implement "EFI Boot Guard" and "SWUpdate" (x86 platform). Most things are already working. Update partition (rootfs) is selected dynamically via uuid. The only problem i have is that the rootfs path in the kernel argument on both ebg config partitions are the same. Does anyone work with ebg/swupdate and have a hint for
<Tom25>
me?
<rburton>
rob_w: if the architecture is the same it will be shared
<rob_w>
ok .. but how to i set MACHINE to ? switching around in my local.conf or
<rburton>
yeah
<rburton>
if they're actually part of the same 'system' then look at multiconfig
goliath has joined #yocto
<rob_w>
thx
prabhakarlad has quit [Quit: Client closed]
alejandrohs has quit [Ping timeout: 240 seconds]
alejandrohs has joined #yocto
Vonter has quit [Ping timeout: 245 seconds]
Vonter has joined #yocto
Guest63 has joined #yocto
luc4 has quit [Ping timeout: 258 seconds]
Tom47 has quit [Quit: Client closed]
Tom25 has quit [Quit: Client closed]
Tom45 has joined #yocto
Tom45 has quit [Client Quit]
Danct12 has quit [Read error: Connection reset by peer]
rob_w has quit [Quit: Leaving]
florian has quit [Quit: Ex-Chat]
<Guest63>
Hi, Is there a way to add a task to all dependencies of a recipe ? I would like to group all the .debug/ELF files in a common folder. I want to avoid using INHERIT at a distro level.
florian_kc has quit [Ping timeout: 258 seconds]
slimak has quit [Ping timeout: 258 seconds]
<qschulz>
Guest63: nope, a recipe can only impact itself
<Guest63>
So the other way would be to bbappend all the dependencies ?
<qschulz>
Guest63: why exactly do you want all ELF files in a common folder?
<qschulz>
Guest63: if all the ELF files are part of the sysroot, then they should be available in your recipe that depends on all other
<rburton>
the debug won't be though
<qschulz>
you could probably do some "smart" stuff there
<rburton>
you could generate a minimal debugfs with just the recipe you care about it, that will pull in the deps and give you a tarball of .debug files
kscherer has joined #yocto
paulg has quit [Ping timeout: 245 seconds]
<Guest63>
I was thinking of adding a step between do_package and do_package_rpm and get the -dbg folder
<rburton>
yeah that's just complicating matters
<Guest63>
but this won't get dependencies like opencv etc
<Guest63>
The other way I was thinking is to catch all the dbg RPM at the end and extract them. But I thought we could do something smart during the build time.
<rburton>
it worked when i tried it but that was 4 years ago, but dbg packages only depend on other dbg packages
<rburton>
so... should work
olani- has left #yocto [Using Circe, the loveliest of all IRC clients]
l3s8g has joined #yocto
slimak has joined #yocto
<tlwoerner>
qschulz: awesome review, thanks! i'll post the fixups to the mailing list (and i did push them to my github copy too)
Danct12 has joined #yocto
ray-san has quit [Remote host closed the connection]
paulg has joined #yocto
<JPEW>
RP: Going to miss bug triage. Meeting conflict. Will have the updated SPDX patch in ~1 hour
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
nemik has quit [Remote host closed the connection]
varjag has quit [Quit: ERC (IRC client for Emacs 27.1)]
olani_ has left #yocto [Using Circe, the loveliest of all IRC clients]
<tlwoerner>
huh, do_deploy() can't be machine-specific? i.e. do_deploy:rk3588() {...}
<Saur>
RP: Regarding your recent change to where the licenses are deployed: wouldn't it make sense to add SSTATE_PKGARCH to PKGDATA_VARS so that it is saved and can be used in, e.g., write_license_files() to directly access the correct file rather than having to search over all possible archs?
fray has quit [Ping timeout: 246 seconds]
mckoan is now known as mckoan|away
ptsneves has joined #yocto
kpo has joined #yocto
fray has joined #yocto
tgamblin has quit [Quit: Leaving]
<JPEW>
RP: Patch sent. Mostly just reworked to be more explicit about the path expectations
linfax has quit [Ping timeout: 248 seconds]
<qschulz>
tlwoerner: ah you need an empty one for the non-machine-specific one
<qschulz>
do_deploy() {:}
<qschulz>
tlwoerner: I assume this is what we're talking about :)
<tlwoerner>
qschulz: i'm working on adding a rk3308-based board that i have, it also doesn't have support in tf-a
florian_kc has joined #yocto
<tlwoerner>
so i was looking to add it to as a second COMPATIBLE_MACHINE to your rkbin recipe
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
goliath has quit [Quit: SIGSEGV]
Guest63 has quit [Ping timeout: 258 seconds]
<tlwoerner>
and ideally i would have do_deploy:rk3588() and do_deploy:rk3308()
<tlwoerner>
i think i've seen another bsp somewhere that had the same issue. i think it's a matter of having one do_deploy() then some logic in there
kpo has quit [Read error: Connection reset by peer]
<tlwoerner>
qschulz: i had a long think about the rk3588 vs rk3588s thing.
<tlwoerner>
i believe we want both rk3588 and rk3588s in MACHINEOVERRIDES for conf/machine/include/rk3588.inc
<tlwoerner>
but only rk3588 in SOC_FAMILY
<tlwoerner>
whereas MACHINEOVERRIDES for rk3588s should only have rk3588s, and its SOC_FAMILY should be rk3588s
<RP>
Saur: that would work for some cases but not all of the functions unfortunately, there aren't dependencies between the license class code and the pkgdata code
<RP>
JPEW: thanks!
<tlwoerner>
i believe i've got that straightened out now, but i don't think it was like that initially
jmiehe has quit [Remote host closed the connection]
<Saur>
Hmm, ok. Anyway, even if you are not accepting a patch to do it, I did it for us since we of course have a lot of code to gather and generate the license info we include in our products, which of course now need that variable to determine the correct path. The dependencies should not be a problem for us since that code runs at the very end. However, what I did notice when I added SSTATE_PKGARCH to PKGDATA_VARS was that nothing rebuilt, a
<Saur>
nd thus the SSTATE_PKGDATA did not end up in the packagedata files. Not until I did a cleansstate and rebuilt. It turns out that do_package (or more specifically emit_pkgdata()) does not depend on PKGDATA_VARS.
<yocton>
sakoman: The patch I was talking about did not apply cleanly on kirkstone anyway, I've backported it and sent it to the ML.
<sakoman>
yocton: OK, thanks! I'll watch for it
<Saur>
RP: I was under the belief that the new addpylib should help with automatically detecting dependencies on bitbake variables used in the Python modules?
<RP>
Saur: I mean task dependencies. pkgdata is only readable if the files exist on disk
<Saur>
RP: Ok, got it. We already have the dependencies in place for our task as it already depends on reading the packagedata files.
<RP>
Saur: right, I'm not sure that is something we can assume
sakman has joined #yocto
<Saur>
RP: What about addpylib? Is my understanding of how much it helps with automatically calculating dependencies on bitbake variables a misunderstanding.
ptsneves has quit [Ping timeout: 260 seconds]
ptsneves has joined #yocto
tnovotny has quit [Quit: Leaving]
ptsneves has quit [Remote host closed the connection]
<RP>
Saur: it should help with dependencies on variables, that is correct
Vonter has quit [Ping timeout: 240 seconds]
Vonter has joined #yocto
<Saur>
RP: Ok, is there any way of seeing it in action, i.e., in trying to figure out why the dependency from emit_pkgdata() on PKGDATA_VARS is not picked up automatically?
<Saur>
Or should I just send a patch to add the vardeps manually?
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
ptsneves has joined #yocto
zpfvo has quit [Ping timeout: 246 seconds]
<RP>
Saur: I'm struggling to process the different directions I'm being pulled in at once, to the point I'm actually physically shaking which is a bit disconcerting. What I'm failing to recall is where the code is but I suspect it will come back to me in a minute so give me some time to think...
<Saur>
RP: No worries, take your time.
Minvera has joined #yocto
l3s8g has quit [Remote host closed the connection]
<RP>
Saur: lib/bb/codeparser.py enable the bb.warn("%s: %s\nRefs:%s Execs: %s %s %s" % (name, fn, parser.references, parser.execs, parser.var_execs, parser.contains)) (there is a bug where src should be fn)
l3s8g has joined #yocto
<RP>
Saur: that will give you debug at least
<Saur>
Ok, I'll see if I can come up with anything. :)
ptsneves has quit [Ping timeout: 246 seconds]
<RP>
Saur: meta/lib/oe/__init__.py needs packagedata adding to BBIMPORTS, that is why it isn't being handled
<RP>
Saur: what that breaks test wise will be "fun"
<Saur>
Does it make sense to add it?
<RP>
Saur: yes, I just wonder if all the sigs tests will still pass
slimak has quit [Ping timeout: 245 seconds]
<Saur>
Btw, looking at meta/lib/oe/__init__.py and listing the modules in meta/lib/oe: what determines which modules are added to BBIMPORTS and which are left out?
<RP>
Saur: BBIMPORTS copied what the code in base.bbclass did. So you're asking why some were listed there and some weren't
<RP>
I'm not sure, I suspect bugs in some cases and code pollution in others
<Saur>
What are the drawbacks of adding modules to BBIMPORTS? (I assume there are some, or they would just have all been added.)
<RP>
There were drawbacks to the base.bbclass imports including circular reference issues and dependency problems. pyaddlib was designed to avoid a lot of them
<RP>
Saur: short answer is I don't remember if there are any or not
<Saur>
Ok.
<Saur>
RP: You were worried about sig test if packagedata is added to BBIMPORTS. Which tests are that exactly? Thought I'd give it a shot, but I prefer to not run all of oe-selftest if I can avoid it....
<RP>
Saur: sstatetests
<Saur>
Thank you.
* RP
wishes he could avoid running it
manuel_ has joined #yocto
Ram94 has joined #yocto
manuel1985 has quit [Ping timeout: 240 seconds]
manuel_ has quit [Ping timeout: 240 seconds]
Ram94 has quit [Quit: Client closed]
<RP>
Saur: I've thrown it into master-next along with a load of other things, we'll see what breaks from this
mvlad has quit [Remote host closed the connection]
khem has quit [Quit: Connection closed for inactivity]
Soopaman has joined #yocto
Minvera2 has joined #yocto
Soopaman has quit [Quit: Leaving.]
Soopaman has joined #yocto
goliath has joined #yocto
<Saur>
RP: I have verified that with your addition of packagedata to BBIMPORTS, I can see the dependency on PKGDATA_VARS being added for the do_package task (and some other dependencies as well).
Soopaman has quit [Quit: Leaving.]
<Saur>
RP: There is one thing I do not understand though. When I ran bitbake-dumpsig -D -t v86d package (I used the v86d recipe for testing since it has basically no dependencies), I noticed that the name of the sigdata file was the same both with and without your fix. I had, however, expected it to change as the contents change...
amitk has quit [Ping timeout: 258 seconds]
tnovotny has joined #yocto
l3s8g has quit [Quit: l3s8g]
ptsneves has joined #yocto
alessioigor has quit [Quit: alessioigor]
khem has joined #yocto
<khem>
RP: do you see issues with llvm 17 patch ?
<RP>
khem: abelloni did I think
<RP>
Saur: Offhand I don't know
<khem>
ok
<khem>
I will wait for details
manuel_ has joined #yocto
ykrons has quit [Ping timeout: 240 seconds]
ykrons has joined #yocto
vladest has quit [Quit: vladest]
vladest has joined #yocto
Ram94 has joined #yocto
Ram94 has quit [Client Quit]
Wouter0100670440 has quit [Remote host closed the connection]
florian_kc has quit [Ping timeout: 240 seconds]
<abelloni>
RP: khem: I had the same issue without llvm 17
<abelloni>
so I guess the patch is ok
<RP>
abelloni: ok, thanks
<abelloni>
my issue is librsvg failing to build on qemux86-64-x32
ptsneves has quit [Ping timeout: 252 seconds]
<yates_work>
is there a way to .bbappend a recipe but have it named something else? i need to .bbappend qtbase_git%.bb, but I want it named qtbase-static
<yates_work>
in other words, when i "bitbake qtbase", i want that to build the original without the .bbappend
<yates_work>
but i don't want to copy the whole recipe and tweak a hundred file names. it is only one or two PACKAGE_CONFIG options I need to change
<JPEW>
yates_work: You can do some limited amount of that with BBCLASSEXTEND, but it's pretty tricky
brazuca has joined #yocto
<yates_work>
JPEW: ok reading up on BBCLASSEXTEN
<yates_work>
D
<JPEW>
We have a (probably really gross) class called virtvariant.bbclass that gives us the ability to have a lot of version of a recipe with different overrides to keep our recipes more or less sane
* JPEW
should upload it somewhere, but I'm afraid it will blind some of the more seasoned devs
<yates_work>
then it'll probably kill me!
<RP>
JPEW: I've seen a class like this before :/
<JPEW>
Ya... it's messy, but it works for what we need
<JPEW>
(which is TBH pretty limited)
<RP>
JPEW: I'm sure we did used to have something like this somewhere public. We ended up not needing it though (thankfully!)
<RP>
core-image-ptest-* is probably one of the more crazy public usages of it :)
<JPEW>
Ya. I'm not sure what the better option is for our use though; we just need to make a few small modifications to a recipe (usually, per product)
<RP>
JPEW: it is fine, it was designed for that kind of thing
<RP>
bitbake internally could handle it more performantly but such is life
tnovotny has quit [Quit: Leaving]
alimon has quit [Remote host closed the connection]
<abelloni>
at least, it is not False is not True ;)
<RP>
abelloni: I have tried to remove a load of those but there are so many left
<RP>
abelloni: I guess False is True would be worse
<abelloni>
:)
<RP>
None is not True or False
<abelloni>
khem: I guess you are going to look at why the musl patches failed?
kscherer has quit [Quit: Konversation terminated!]
Xagen has quit [Ping timeout: 244 seconds]
sakman has quit [Ping timeout: 260 seconds]
<RP>
Saur: I did bitbake-dumpsig tmp/stamps/qemux86_64-poky-linux/v86d/0.1.10.do_package.sigdata.8a* | grep emit and I see emit_pkgdata listed
<RP>
Saur: comparing old files with new ones, I see it changes to List of dependencies for variable oe.packagedata.emit_pkgdata is ['ALLOW_EMPTY', 'MLPREFIX', 'MULTILIB_GLOBAL_VARIANTS', 'MULTILIB_VARIANTS', 'PACKAGES', 'PKGDATA_VARS', 'PKGDEBUGSOURCES', 'PKGDEST', 'PKGDESTWORK', 'PN', 'RPROVIDES', 'oe.packagedata.glob', 'oe.path.symlink'] from an empty list previously
khem has quit [Quit: Connection closed for inactivity]
florian_kc has quit [Ping timeout: 258 seconds]
luneff has joined #yocto
luneff has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]