<vmeson>
moto-timo: I see. I'll try that tomorrow.
<moto-timo>
vmeson: it might be something else with build_rust… the message is kind of a catch all
amitk has joined #yocto
camus has quit [Ping timeout: 248 seconds]
paulg has quit [Remote host closed the connection]
cocoJoe has joined #yocto
camus has joined #yocto
<RP>
and of course rust failed after merging
rob_w has joined #yocto
thekappe has joined #yocto
LetoThe2nd has joined #yocto
<LetoThe2nd>
yo dudX
<thekappe>
hello man ! XD
grma has quit [Ping timeout: 240 seconds]
<thekappe>
guys, I have one question. I have a recipe that build multiple binaries and a shared library. What I wan to do is to have all the binaries into a package and the share library into another one. Next thing is that if I add the package containing the binaries to image I need the shared library to be installed too. THere is a way to tell the recipe that if the binary package is selected, the library package is
<thekappe>
automatically installed too ?
cocoJoe has quit [Quit: Client closed]
cocoJoe has joined #yocto
<barath>
thekappe: you need to make the package containing the libraries be a dependency (see the DEPENDS variable in the yocto manual) of the package containing the binary
<barath>
and to create multiple packages in the same recipe, containing different binaries, you can declare multiple FILES_libs<pn>=" {libdir}/*.so " variables etc
<barath>
I'm not sure where in the manual it talks about the latter...
<barath>
thekappe: note that some runtime-dependencies (RDEPENDS) are automatically added to packages sometimes, when yocto sees that a binary is linked against a certain library
<thekappe>
ok ! I didn't know that ! thanks again !
<barath>
:)
fleg has joined #yocto
zyga has joined #yocto
bps has quit [Ping timeout: 240 seconds]
leon-anavi has joined #yocto
Guest19 has joined #yocto
florian has joined #yocto
hansihe has joined #yocto
<hansihe>
I have a bitbake recipe which is building a meson project. It inherits both `meson` and `pkgconfig`. In the `meson.build` file, there are calls to `<dep>.get_pkgconfig_variable('pkgdatadir')`. Unfortunately this seems to return a path in my native harddrive root, `/usr`, not in the sysroot for the package like I would expect. I understand that `PKG_CONFIG_SYSROOT_DIR` needs to be set when `pkg-config` is invoked for it to return the right
<hansihe>
path, this should be handled by meson.bbclass, right?
bps has joined #yocto
bps has joined #yocto
<LetoThe2nd>
hansihe: have you looked at other comparable recipes? i'd expect it to be handled correctly, but it might be depending on inherit ordering.
grma has joined #yocto
zyga-mbp has quit [Ping timeout: 248 seconds]
jorschulko has joined #yocto
Guest19 has quit [Quit: Client closed]
zyga-mbp has joined #yocto
camus has quit [Ping timeout: 250 seconds]
<hansihe>
meson seems to have a `sys_root` option in their `meson.cross`, which is what meson uses to set their `PKG_CONFIG_SYSROOT_DIR`, but that option is not set in the poky `meson.bbclass`
<hansihe>
I might have missed something, but I don't understand how this can work at all in the general case
<jorschulko>
Hi, I was wondering how well (if at all) yocto (dunfell) can handle simultaneous builds writing to the same sstate cache?
camus has joined #yocto
goliath has joined #yocto
leonanavi has joined #yocto
fleg has quit [Ping timeout: 252 seconds]
Bardon has joined #yocto
Bardon_ has quit [Ping timeout: 252 seconds]
goliath has quit [Ping timeout: 252 seconds]
leon-anavi has quit [Ping timeout: 252 seconds]
leonanavi is now known as leon-anavi
goliath has joined #yocto
fleg has joined #yocto
kayterina has joined #yocto
k4wsys[m] has joined #yocto
<qschulz>
yes
<jorschulko>
qschulz: was that an answer to my question? :D
<qschulz>
yes :)O
<qschulz>
as per JPEW "You need proper file locking IIRC, so either a local file syetem or NFS"
<jorschulko>
ah nice! the same doesn't hold true for the download dir by any chance? :)
<qschulz>
of course
<jorschulko>
that just made my life a lot easier :D thanks!
goliath has quit [Quit: SIGSEGV]
tre has joined #yocto
jorschulko has quit [Quit: leaving]
jorschulko has joined #yocto
rob_w has quit [Quit: Leaving]
jorschulko has quit [Client Quit]
jorschulko has joined #yocto
jorschulko has quit [Client Quit]
Vonter has quit [Ping timeout: 250 seconds]
eduardas has joined #yocto
kanavin_ has joined #yocto
kanavin has quit [Ping timeout: 252 seconds]
Vonter has joined #yocto
goliath has joined #yocto
tnovotny has joined #yocto
camus has quit [Ping timeout: 248 seconds]
camus has joined #yocto
prabhakarlad has joined #yocto
jwillikers has joined #yocto
argonautx has joined #yocto
BCMM has joined #yocto
jwillikers has quit [Remote host closed the connection]
jwillikers has joined #yocto
<override>
yo, how can we update the device tree without flashing entire new images?
<LetoThe2nd>
override: it DEPENDS.
<override>
LetoThe2nd: im just trying to hearout all possible options
<override>
since I havent got the slightest clue
<LetoThe2nd>
override: no, it doesn't work like that. because it completely depends on your development setup, and where the kernel gets the current dtb from.
<override>
LetoThe2nd: did you want me to show you my current .wks file or something? Trying to understand what all I need to let you know
ferlzc has joined #yocto
<override>
Im trying to see if I can add a var to boot.src or something and have uboot load the device tree from there
<override>
thats the kinda of options im trying to figure out
<LetoThe2nd>
again, it depends. uboot can fetch from sd card, for example. from tftp. from nfs.
<override>
or someone can just tell me a little more about device tree overlays
<LetoThe2nd>
if uboot uses the same, then things are more complicated.
rpcme has joined #yocto
<LetoThe2nd>
and overlays are something completely else again too.
<override>
LetoThe2nd: my uboot and all the other partitions get flashed to the emmc
<qschulz>
check where the device tree is gotten from
<qschulz>
you might be lucky and it gets it from a partition mounted in the rootfs (or the fs directly)
<qschulz>
it's not uncommon to have them in /boot
<override>
I also read something about the device-tree-compiler, apparenlt lets you edit the device tree during runtime
<qschulz>
but again, depends on U-Boot, you can perfectly have device tree in /boot but not have those used
<override>
well my wks is setup to have a boot partition
<override>
unclear where exactly my devitree tree is at
<qschulz>
no, that's not possible, you can apply device tree overlays at runtime but it isn't mainline as far as i know
<override>
should i just do a find -name *dts or something on the boards?
<qschulz>
dtc is just to produce dtb (device tree blob) or dtbo (device tree overlay blob)
<LetoThe2nd>
usually one would patch the uboot-env to pull the dtb from some connected storage. no wks involved.
<qschulz>
14:27:11 qschulz | you might be lucky and it gets it from a partition mounted in the rootfs (or the fs directly)
<qschulz>
insinuate it might not be
<qschulz>
and 14:27:50 qschulz | but again, depends on U-Boot, you can perfectly have device tree in /boot but not have those used
<qschulz>
you have to dig into U-Boot environment variables to understand how and where the device tree is gotten from
<override>
alright, first thing first, whats like a sure shot way of finding out where the bsp is currently storing the device tree at?
<qschulz>
yoiu can also have uImage and fitImage, which have the device tree embedded, so many ways and as LetoThe2nd said "it depends"
<override>
qschuls: so look at the bootscr file?
<qschulz>
usually the command run at boot when U-boot is uninterrupted is stored in `bootcmd`
<qschulz>
start from there
<qschulz>
it might use bootscr, might not
<override>
got it
<override>
and if its setup the bootcmd its prolly just sitting the rootfs?
<override>
the bootcmd way **
<qschulz>
bootcmd is a variable, it contains something
<qschulz>
can be whatever
tp43_ has joined #yocto
davidinux has quit [Ping timeout: 240 seconds]
davidinux has joined #yocto
zyga-mbp has quit [Ping timeout: 250 seconds]
zyga-mbp has joined #yocto
cocoJoe has quit [Ping timeout: 246 seconds]
<tlwoerner>
you can also append the dtb to a zImage, in which case the only way to update it is to write a new kernel+dtb and reboot
<tlwoerner>
it's called: "being flexible" ;-)
<smurray>
fit image is another option, it can hold multiple kernels and dtbs iirc
paulg has joined #yocto
<qschulz>
tlwoerner: isn't that the uImage format?
<qschulz>
smurray: yup, even dtbos too
<qschulz>
rootfs, scripts, firmware, etc...
<tlwoerner>
qschulz: CONFIG_ARM_APPENDED_DTB says: "With this option, the boot code will look for a device tree binary (DTB) appended to zImage"
<qschulz>
tlwoerner: great, another format :p
<qschulz>
so I guess this works fine with bootz /me thinks
<tlwoerner>
that's exactly what bootz is for
<tlwoerner>
most "current" SoCs/platforms are moving to fitImages, appending the dtb to a zImage (for example) is something you'd find with older boards
<tlwoerner>
uImages and zImages are slowing going away
goliath has quit [Quit: SIGSEGV]
<qschulz>
yeah, bootm is for uImage/fitImage and bootz for zImage, so appended zImage probably work with bootz that's what I meant
<qschulz>
and the damn booti for Image (aarch64 at least)
<qschulz>
so many ways to boot stuff :p
<override>
qschulz: tlwoerner: i tried looking into the uboot env vars and they seems really freakin confusing. the only thing remotely similiar to device trees in there is something called eft_dtb
<override>
similar*
mihai has quit [Remote host closed the connection]
<override>
what format is efi?
<tlwoerner>
qschulz: additionally you could also enable extlinux, for example, which has u-boot looking for an extlinux.conf which tells it what to do
<override>
tlwoerner: my uboot using some standard way of setting up the variables, it was called distro or something, cant remember. Im trying to see how I can update the device tree from this distro style uboot
<tlwoerner>
"distro booting" perhaps
<tlwoerner>
the u-boot sources don't contain anything about eft_dtb or eft
<override>
more like efi_dtb
<tlwoerner>
what's the SoC?
<override>
toradex
sethfoster has joined #yocto
<sethfoster>
Anybody here mess around with meta-clang?
<sethfoster>
or the OSSystems meta-browser layer?
<tlwoerner>
override: does you device have a /boot/extlinux directory?
<tlwoerner>
sethfoster: once in a while i try building the chromium browser for x11 from the meta-browser layer. although i haven't tried in the last 2 months or so
mbrothers has joined #yocto
tre has quit [Remote host closed the connection]
<override>
tlwoerner: /boot seems to be empthy :/ I did find a carve out for the device tree binary file in boot.scr and the uboot env... trying to figure out partiton device tree binary lives in now..
<override>
empty*
<tlwoerner>
override: my impression is toradex is pretty well supported, there's probably someone there you can contact for help?
<sethfoster>
oh hey override: im working on a verdin imx8mm right now
<sethfoster>
don't have irc history tho, missed what you asked
tp43_ has joined #yocto
<sethfoster>
tlwoerner: i'm trying to get some stuff to build electron going, problem ended up being that meta-clang had some dynamic-layer overrides for chromium that didn't get applied because my recipe's named something else
BCMM has quit [Ping timeout: 248 seconds]
camus has quit [Quit: camus]
tnovotny has quit [Quit: Leaving]
zyga-mbp has quit [Ping timeout: 240 seconds]
zyga-mbp has joined #yocto
eduardas has quit [Quit: Konversation terminated!]
<moto-timo>
vmeson: somehow I had some cruft in recipe-sysroot-native from prior hacks, "successfully" built python3-cryptography with python3-setuptools-rust-native... now to figure out the ptest mess
mattsm has quit [Read error: Connection reset by peer]
mattsm has joined #yocto
ferlzc has quit [Ping timeout: 240 seconds]
kayterina has quit [Remote host closed the connection]
tp43_ has quit [Ping timeout: 250 seconds]
<vmeson>
moto-timo: yay! I see your fix on the oe-core list. Thanks!
zyga has quit [Quit: Leaving]
dev1990 has joined #yocto
bps has quit [Ping timeout: 250 seconds]
sethfoster has quit [Quit: Lost terminal]
<tgamblin>
vmeson: moto-timo: building it too. I should be able to help with the ptests shortly... rust-native do_compile right now
tp43_ has joined #yocto
bps has joined #yocto
bps has joined #yocto
goliath has quit [Quit: SIGSEGV]
tp43_ has quit [Ping timeout: 245 seconds]
LetoThe2nd has quit [Quit: Connection closed for inactivity]
mbrothers has quit [Ping timeout: 252 seconds]
zyga-mbp has quit [Ping timeout: 248 seconds]
zyga-mbp has joined #yocto
<WadeBerrier[m]>
Anyone have any suggestions for pruning a shared state cache over time? Or, do we just blow it away once in a while and re-populate it?
<JPEW>
WadeBerrier[m]: We delete it every Friday. Depends on what you need, there is also a script to prune it more methodically
<JPEW>
scripts/sstate-cache-management.sh
<WadeBerrier[m]>
JPEW: Nice. Mind pointing me to this script?
<WadeBerrier[m]>
Heh, just saw the path, thanks!
florian has quit [Quit: Ex-Chat]
<JPEW>
It's in oe-core/poky
<JPEW>
oe-core or poky that is ;)
leon-anavi has quit [Quit: Leaving]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zyga-mbp has joined #yocto
florian has joined #yocto
whuang0389 has joined #yocto
florian has quit [Ping timeout: 250 seconds]
<whuang0389>
Im getting a bunch of set scene errors that I never previously saw. Any ideas why? ERROR: Setscene task /home/whuang/yocto/build/../sources/poky/meta/recipes-connectivity/openssh/openssh_8.2p1.bb:do_populate_sysroot in both covered and notcovered.
tp43_ has joined #yocto
<vmeson>
moto-timo: librsvg seems to build meta/recipes-gnome/librsvg/librsvg_2.50.1.bb -- I''ll update to 2.50.7 when I'm back from an errand.
<moto-timo>
vmeson: hazaah!
zeddii has quit [Ping timeout: 248 seconds]
zeddii has joined #yocto
florian has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tp43_ has quit [Ping timeout: 250 seconds]
zyga-mbp has joined #yocto
<vmeson>
whuang0389: is that set scene error on master or ??? Also poky or oe-core or some other distro?
<whuang0389>
no its on dunfell. im assuming i ran out of disk space or something.. trying to rebuild on a larger disk
<whuang0389>
and yea it's poky-base distro
zyga-mbp has quit [Ping timeout: 240 seconds]
<vmeson>
whuang0389: That's odd, I'm pretty sure that dunfell has a default monitor to stop the build if the FS free space is low. Let us know if the larger disk helps.
<vmeson>
I doub that sakoman broken anything on dunfell but I guess it's possible.
zyga-mbp has joined #yocto
<sakoman>
vmeson: I'm not aware of any dunfell breakage. If there is I want to know about it!
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<paulg>
"I dun' fell and broke mar hip."
<paulg>
(you'll have to imagine your own instance of a redneck accent for that)
abelloni has quit [Ping timeout: 240 seconds]
abelloni has joined #yocto
whuang0389 has quit [Quit: Client closed]
<sakoman>
paulg: I always wondered where the dunfell name came from :-)