sakman_ has quit [Remote host closed the connection]
qschulz has quit [Quit: qschulz]
brazuca has quit [Quit: Client closed]
qschulz has joined #yocto
dlan has joined #yocto
davidinux has quit [Ping timeout: 244 seconds]
davidinux has joined #yocto
sgw has quit [Ping timeout: 260 seconds]
kscherer has quit [Quit: Konversation terminated!]
Ablu has quit [Ping timeout: 240 seconds]
luneff has quit [Ping timeout: 264 seconds]
Ablu has joined #yocto
sgw has joined #yocto
luneff has joined #yocto
starblue has quit [Ping timeout: 264 seconds]
starblue has joined #yocto
arob109 has quit [Read error: Connection reset by peer]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
jclsn has quit [Ping timeout: 260 seconds]
jclsn has joined #yocto
nerdboy has quit [Ping timeout: 244 seconds]
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
GNUmoon has quit [*.net *.split]
zelgomer has quit [*.net *.split]
zelgomer has joined #yocto
zelgomer has quit [Remote host closed the connection]
zelgomer has joined #yocto
sugarbeet has quit [Ping timeout: 260 seconds]
sugarbeet has joined #yocto
amitk has joined #yocto
<yates_work>
i'm attempting to build meta-qt5/recipes-qt/qt5/qtbase with the configure modification of static and linuxfb as follows: https://bpa.st/NM2A
<yates_work>
that is qtbase-static.bb ^^^^ however it appears there the qtbase package config options are not being pulled in: https://bpa.st/BLGQ
<yates_work>
wait - the ssstatecache may have gotten hosed. i'm removing and rebuilding from scratch
mrpelotazo has quit [Quit: Hasta la vista!]
mrpelotazo has joined #yocto
mrpelotazo has quit [Read error: Connection reset by peer]
<eenuts>
hi, is there a way to ship compiled python files rather than the plain .py files?
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 258 seconds]
<ad__>
hi, about meta-toolchain-qt6, in hardknott, building it i am getting
<ad__>
ffmpeg was skipped: because it has a restricted license 'commercial'
<ad__>
shouldn't be open stuff ?
zpfvo has joined #yocto
Kubu_work has joined #yocto
<qschulz>
tlwoerner: I can send something for using the variables yes.
<qschulz>
tlwoerner: as for the u-boot%.bbappend to u-boot_%.bbappend rename, I don't know that's up to you. I am actually glad it's there because I don't have to have it copied verbatim to apply to my vendor recipes
<mischief>
eenuts: we wrote a class for it that runs as part of image generation
<mischief>
something like ${PYTHON} -BOO -m compileall -f --invalidation-mode unchecked-hash ${IMAGE_ROOTFS}${libdir} for your ROOTFS_POSTPROCESS_COMMAND
efeschiyan has quit [Client Quit]
efeschiyan has joined #yocto
olani_ has quit [Remote host closed the connection]
olani- has quit [Remote host closed the connection]
olani- has joined #yocto
GNUmoon has joined #yocto
olani- has quit [Ping timeout: 258 seconds]
<qschulz>
tlwoerner: not sure there's something we can do for linux-yocto%.bbappend though
<qschulz>
but since you need TF-A on aarch64 to boot a Linux kernel, I feel like this is something that would have its place in meta-arm?
slimak has joined #yocto
<yates_work>
ok i rebuilt after removing the cache, sstate-cache, and tmp files and am getting the same error: https://bpa.st/BLGQ
leon-anavi has joined #yocto
<yates_work>
nm, i see the problem: NONE of those PACKAGE_CONFIG options are valid
<yates_work>
evidently when A DEPENDS (on) B, that does not mean that A will be run in the "variable context" of B
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<yates_work>
i guess i need A to be a .bbappend of B?
<qschulz>
yates_work: it actually means the complete opposite :) anything in B context won't appear in A context
<qschulz>
yates_work: and I won't go into task contexts :)
Vonter has quit [Ping timeout: 260 seconds]
Vonter has joined #yocto
<yates_work>
qschulz: well is a .bbappend the way to get where i'm going?
<yates_work>
"Lists a recipe’s build-time dependencies"
<qschulz>
yates_work: if you want to enable packageconfig features to a package, you need to use a bbappend yes
<yates_work>
it means B has to be run (at least up through some syroot-generating task) before A
<yates_work>
ok
florian has joined #yocto
<qschulz>
yates_work: haven't followed your questions, so don't know what you're trying to do or what A and B are for you
<yates_work>
A is a static build of qtbase, B is qtbase
GNUmoon has quit [Remote host closed the connection]
<yates_work>
(which is dynamic by default)
<qschulz>
would you have TWO qtbase on your system, one static and one dynamic?
GNUmoon has joined #yocto
<yates_work>
no
<rburton>
can't a single recipe do both and split the packaging up like every other library does?
<qschulz>
rburton: oh very good point, if the recipe supports building .so AND .a then maybe not much needs to be done
<qschulz>
yates_work: do you need the static files of qtbase on your filesystem or just use it as a dependency from another recipe which is then going to be statically compiled?
<yates_work>
qschulz: correction: well yes, it could have both. i don't need the dynamic for my (eventual) applicaiton recipe that is going to be linked statically to qtbase
<qschulz>
yates_work: isn't the .a file already installed in the sysroot of your other recipe?
<yates_work>
qschulz: re: "do you need the static files.." - no, i just need the .a to be in yocto when i build my applicaiton recipe
<yates_work>
re: "isn't the..." let me check
<rburton>
the stock qtbase qt5 recipe appears to build static libraries
<rburton>
so what's the problem?
<yates_work>
but wait, it's not JUST that i need the .a versions of qt. i also need to build qt differently, using the "linuxfb" package config
<rburton>
so use a bbappend to set that packageconfig
<rburton>
or distro.conf overrides
slimak has quit [Ping timeout: 258 seconds]
<qschulz>
tlwoerner: if you have boot logs for rock5b maybe I can triple guess something
tgamblin has joined #yocto
<yates_work>
rburton: well, i want to keep the recipe name "qtbase" to operate the same in my layer. if i use a .bbappend as you state, wouldn't that modify the result of "bitbake qtbase"?
<rburton>
are you trying to say that you want two copies of qt, built differently?
prabhakarlad has joined #yocto
<yates_work>
yes, that is what i saying. (but i didn't realize it..)
<yates_work>
i'm
<yates_work>
well wait...
<yates_work>
no, i do not mean that. i only need one qtbase built with that different package config and including qtbase .a file(s) (Qt5Core.a, e.g.). so all i need to do is make a .bbappend as you said.
<yates_work>
ok i'm good (... i think?)
<yates_work>
thank you rburton and qschulz.
<rburton>
you literally just need a bbappend to set the packageconfig you need
<yates_work>
right, i think so now.
<yates_work>
rburton: but how do you know the original qtbase builds .a files?
<yates_work>
it builds .a as well as dynamic .so?
<qschulz>
yates_work: look into the WORKDIR of qtbase and you'll know
<rburton>
the recipe has a FILES:$PN-staticdev
<rburton>
but oe-pkgdata-util list-pkg-files will tell you
<rburton>
you determine if a recipe built files by asking what files were packaged, and that's oe-pkgdata-util's job
Estrella_ has quit [Read error: Connection reset by peer]
Estrella_ has joined #yocto
zpfvo has quit [Ping timeout: 258 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 264 seconds]
zpfvo has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
zpfvo has quit [Ping timeout: 258 seconds]
zpfvo has joined #yocto
olani- has joined #yocto
olani_ has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
prabhakarlad has joined #yocto
manuel1985 has joined #yocto
slimak has joined #yocto
varjag has quit [Quit: ERC (IRC client for Emacs 27.1)]
kpo has joined #yocto
<qschulz>
tlwoerner: I meant the linux-yocto one :)
rfuentess has joined #yocto
<tlwoerner>
qschulz: ah! give me a couple minutes
Estrella__ has joined #yocto
<tlwoerner>
qschulz: the device-tree in the 6.4 kernel for the rock5b is quite sad. it doesn't enable the sdmmc so i created a patch to do so for linux-yocto
<tlwoerner>
i guess the developers are using emmc modules?
<rfuentess>
hi!
<tlwoerner>
linux-yocto-dev, 6.5, and later, do enable it, no patch required
<qschulz>
tlwoerner: it's still in active development so not much of a surprise
<qschulz>
tlwoerner: i would suggest to just not support linux-yocto at all? not sure it's worth the maintenance effort for you
<qschulz>
effectively you'd be creating your own vendor tree, but in your meta-rockchip layer...
<qschulz>
tlwoerner: devs have to start somewhere, so maybe eMMC was just the first one to be merged
Estrella___ has quit [Ping timeout: 248 seconds]
<rfuentess>
This sentences implies that if I have GROUPADD_PARAM:${PN} = "user1" ; USERADD_PARAM:${PN} = "--gid suer1 wsplugin" the `--gid` implies the use of the useradd* ? or that is Extra Users?
<qschulz>
tlwoerner: so no need for the logs then
<tlwoerner>
qschulz: right. i think i did the same with rock-pi-e when it came out. i used a -dev kernel (or maybe some home-grown recipe to do the same)
<tlwoerner>
in time it can switch back to linux-yocto once linux-yocto is >= 6.5
<qschulz>
tlwoerner: it'll be a while before there's decent support in the kernel unfortunately
<qschulz>
but a welcome surprise is panthor (open source GPU drivers both kernel and userspace)
<tlwoerner>
qschulz: i just need to incorporate your rk3588/rk3588s things and i'll be ready to post the patch
<qschulz>
fingers crossed it should happen rather soon :)
<qschulz>
tlwoerner: cool, but no worries really :)
<qschulz>
s/worries/hurry/
<qschulz>
tlwoerner: i'll probably ask for a backport to kirkstone since this is still what we're using right now
Minvera has joined #yocto
xmn has joined #yocto
* RP
quietly curses multilib
<qschulz>
LOUDER
kpo_ has joined #yocto
kpo has quit [Ping timeout: 240 seconds]
brazuca has joined #yocto
Xagen has joined #yocto
<yates_work>
can someone please give me a clue how (e.g.) libQt5FbSupport.a is generated as part of the qtbase-staticdev package (meta-qt)? https://bpa.st/J6NA
<yates_work>
i grepped the entire kirkstone for FbSupport and got nothing
<yates_work>
(the augmented kirkstone with meta-qt5 layer added)
<qschulz>
yates_work: look into the compile logs of qtbase?
<qschulz>
WORKDIR/temp/log.do_compile for example
<yates_work>
qschulz: good idea - thanks!
frieder has quit [Remote host closed the connection]
rob_w has quit [Remote host closed the connection]
l3s8g has joined #yocto
zpfvo has quit [Ping timeout: 244 seconds]
zpfvo has joined #yocto
Schlumpf has quit [Ping timeout: 245 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
kpo has joined #yocto
tgamblin has quit [Remote host closed the connection]
kpo_ has quit [Ping timeout: 240 seconds]
kpo has quit [Ping timeout: 258 seconds]
manuel1985 has quit [Ping timeout: 240 seconds]
dvergatal has quit [Ping timeout: 252 seconds]
alejandrohs has joined #yocto
dvergatal has joined #yocto
ptsneves has joined #yocto
leon-anavi has quit [Remote host closed the connection]
<yates_work>
is there a bitbake command to clear all cache and tmp?
ptsneves has quit [Ping timeout: 255 seconds]
<RP>
yates_work: no, since rm does a decent job
dvergatal has quit [Ping timeout: 240 seconds]
dvergatal has joined #yocto
<yates_work>
lol
linfax has quit [Ping timeout: 260 seconds]
<rburton>
yates_work: you're asking "how exactly is qt built?", the answer to that is "ask the qt developers"
<yates_work>
i am bitbaking a recipe for a simple qt application (4 .cpp files) which takes about 15 seconds normally. bitbake has now spent 3h41m. how do i check if it's "stuck?"
<yates_work>
..15 seconds natively...
<yates_work>
it's in the recipe's do_compile
GNUmoon has joined #yocto
brazuca has joined #yocto
astlep55040 has quit [Ping timeout: 240 seconds]
astlep55040 has joined #yocto
<rburton>
yates_work: obviously its stuck
<yates_work>
funny you piped up - i just entered C-c C-c about 3 mintues ago..
<rburton>
"ps axfw" is good to tell you what the task is running, so you can tell if it's blocked or busy doing the same thing over and over
<rburton>
pstree -p -l $(pgrep Cooker) is neat too
<yates_work>
it's killed now. anything i can do post-mortem to find out? i'm looking at the latest stuff in work but that's tedious
<rburton>
the log.do_compile will tell you what the task was running
<rburton>
but obviously at that point you're entirely relying on whatever _your_ task says to output. if it silent builds then you don't get logs
<rburton>
3h for a simple build could either be the makefile/whatever deciding to ask for input (which will never come, as stdin is /dev/null), or it frantically rebuilding the same file over and over
<yates_work>
yah, 84MB log.do_compile. not good.
<yates_work>
rburton: hey, don't get defensive! i know i'm an idiot!
<rburton>
that sounds like repeatedly building the same thing