jwillikers has quit [Remote host closed the connection]
sakoman has joined #yocto
amitk has joined #yocto
tp43_ has quit [Ping timeout: 245 seconds]
sakoman has quit [Quit: Leaving.]
manuel1985 has quit [Quit: Leaving]
kranzo has joined #yocto
sgw has quit [Ping timeout: 258 seconds]
sgw has joined #yocto
frieder has joined #yocto
goliath has joined #yocto
creich_ has quit [Quit: Leaving]
creich has joined #yocto
sbach has quit [Read error: Connection reset by peer]
sbach has joined #yocto
leon-anavi has joined #yocto
zpfvo has joined #yocto
tp43_ has joined #yocto
<kranzo>
if i commit to devtool-override-qemux86-64 , devtool finish is dropping my conditional patches any idea were a fallpit is located in the workflow?
rob_w has joined #yocto
jkolasa has joined #yocto
tre has joined #yocto
goliath has quit [Quit: SIGSEGV]
xmn has joined #yocto
tp43_ has quit [Ping timeout: 258 seconds]
jmiehe has joined #yocto
<kanavin>
kranzo, are you on tip of master?
<kanavin>
also, I think you need to checkout devtool branch before 'devtool finish'
mcon has joined #yocto
bps has joined #yocto
bps has quit [Changing host]
bps has joined #yocto
Guest815 has joined #yocto
<Guest815>
Hi
<Guest815>
In a BSP meta layer merge requests are approved which mainly consist of changing "DEPENDS_append_" to "DEPENDS:append:"
<Guest815>
Did I miss something and is the new style to use a colon ":" instead of lowercase "_" ?
<qschulz>
this will be supported along with the original _ override separator in dunfell, gatesgarth and hardknott IIRC (dunfell and hardknott for sure). Only : will be supported starting from honister
JaMa has joined #yocto
<Guest815>
qschulz got it, thanks!
<kranzo>
kanavin i started from devtool, checkout the overlay branch, commit changes, checkout devtool, devtool finish and the output is telling me no changes need to be applied for the overlay branch
Guest815 has quit [Quit: Client closed]
Guest8 has joined #yocto
* RP
notes pseudo is broken with glibc 2.34. This fills me with dread
<RP>
rburton: also, uninative is bust with glibc 2.34, locale problems in images :(
Guest8 has quit [Ping timeout: 246 seconds]
<RP>
hmm, local uninative broke, upstream one works
florian has joined #yocto
Guest8 has joined #yocto
zyga-mbp has joined #yocto
amitk_ has joined #yocto
jkolasa has quit [Quit: Client closed]
amitk has quit [Ping timeout: 268 seconds]
<rburton>
i saw the locale thing in the changelog and wondered if it would break us
<kanavin>
kranzo, this might be a bug if you are using master. Unfortunately, you need to dig into it.
<kranzo>
ah i'm on hardknott
manuel1985 has joined #yocto
<manuel1985>
When I'm building my image, it tells me: unparsed line: 'PLATFORMSPECIFIC:append:rpi = " userland"'
<qschulz>
manuel1985: check that all your layers are using the correct branch
<qschulz>
I assume the bitbake you're using does not support the : override separator
<qschulz>
poky or bitbake repo needs to be checked out at the correct branch (and up-to-date)
<manuel1985>
qschulz: Ok I'll check again
<qschulz>
or your other layers are too new for the current poky/bitbake repo
<Krisso>
I'm seeing bitbake worker processes parented under systemd pid 1 during build execution - I launch a bash script that sets up a couple of things and then invokes the build and that script is still shows up with a its pid and a single bitbake worker command with a child pid under the shell I ran the script from. but everything else happens under a
<Krisso>
root python3 ->bitbake process tree who's parent is pid is 1 (systemd). I was expecting to see the worker tree under the script invocation. Is this expected? is there an option to not make the workers break away?
<Krisso>
I'm seeing bitbake worker processes parented under systemd pid 1 during build execution - I launch a bash script that sets up a couple of things and then invokes the build and that script shows up with its pid and a single bitbake worker command as a child under the shell I ran the script from (as expected). but everything else eventually happens
<Krisso>
under a root python3 -> bitbake process tree who's parent is pid is 1 (systemd). I was expecting to see the whole worker tree under the script invocation. Is this expected? is there an option to not make the workers break away?
<Krisso>
sorry, got rid of some spelling mistakes and hopefully made it more clear :)
Guest8 has quit [Quit: Client closed]
Guest8 has joined #yocto
zyga has joined #yocto
zyga-mbp has quit [Ping timeout: 245 seconds]
mihai has joined #yocto
Guest8 has quit [Quit: Client closed]
camus1 has joined #yocto
camus has quit [Ping timeout: 245 seconds]
camus1 is now known as camus
prabhakarlad has quit [Quit: Client closed]
Krisso has quit [Quit: Client closed]
angolini_ has joined #yocto
Krisso has joined #yocto
BobPungartnik has joined #yocto
BobPungartnik has quit [Client Quit]
cocoJoe has quit [Quit: Client closed]
prabhakarlad has joined #yocto
camus1 has joined #yocto
jwillikers has joined #yocto
camus has quit [Ping timeout: 245 seconds]
camus1 is now known as camus
jwillikers has quit [Remote host closed the connection]
cocoJoe has joined #yocto
<manuel1985>
Did anyone get X11 or wayland to run on a raspberry pi 4?
kranzo has quit [Quit: Client closed]
camus1 has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
chrysh has joined #yocto
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #yocto
angolini has quit []
angolini_ is now known as angolini
florian has quit [Ping timeout: 268 seconds]
kranzo has joined #yocto
kranzo has quit [Quit: Client closed]
Krisso has quit [Quit: Client closed]
xmn has quit [Quit: ZZZzzz…]
<JPEW>
manuel1985: I've run Wayland on rpi 4
<manuel1985>
<3 <3 <3
<manuel1985>
JPEW: I can't get it to run
<manuel1985>
Don't have the error message at hand, but I think it's about DRM (or DRI?) not available
<JPEW>
manuel1985: it's supposed to work out of the box with oe-core + meta-raspberrypi
<JPEW>
Ah, you need to enable DRM in the bootloader
<tlwoerner>
darn, i had a 3rd agenda item for the meeting but couldn't remember it
<tgamblin>
vmeson: alright, thanks
<tlwoerner>
i'm sitting on a patch to add gcc-sanitizers to the profiling packagegroup, i also want to try to figure out a way to make it easy for a user to add the sanitizers to a build of a given recipe
cocoJoe has quit [Quit: Client closed]
<smurray>
RP: a likely naive question on my part, during parsing are the bitbake-servers that get spun up reused for multiple recipe parses?
<smurray>
RP: or is that all happening in one process and it's just events that happen in new processes?
xmn has joined #yocto
bps has quit [Ping timeout: 268 seconds]
<RP>
smurray: there is a thread pool created and then destroyed for parsing
<kergoth>
RP: heh, if you define a function do_install_appended () {} you get an incorrect warning about use of the old syntax ;)
<kergoth>
s/warning/error/
tp43_ has quit [Ping timeout: 245 seconds]
prabhakarlad has quit [Quit: Client closed]
florian has joined #yocto
xmn has quit [Ping timeout: 258 seconds]
florian has quit [Ping timeout: 258 seconds]
xmn has joined #yocto
dev1990 has quit [Quit: Konversation terminated!]
prabhakarlad has joined #yocto
tp43_ has joined #yocto
frieder has joined #yocto
frieder has quit [Remote host closed the connection]
dev1990 has joined #yocto
<paulg>
does it at least tell you in what file it is ?
marka has quit [Ping timeout: 268 seconds]
marka has joined #yocto
florian has joined #yocto
prabhakarlad has quit [Quit: Client closed]
florian has quit [Ping timeout: 268 seconds]
FO2 has joined #yocto
FO3 has joined #yocto
<FO3>
Hi, we are trying to get multilib to work in our image (dunfell). We get it working; but binaries in /bin /sbin /usr/bin /usr/sbin seem to be a mix of 32 and 64 bits files. I checked multilib.bbclass and it seem to use ALTERTIVE to give priority to 64 bits, but what about recipes without alternates ? Any idea on how to prioritize 64-bits executables for all recipes ?
prabhakarlad has joined #yocto
FO2 has quit [Quit: Leaving]
<Xagen>
paulg: i assume you were talking about my error. it says `../../gsoap/src/soapcpp2` doesn't exist
<Xagen>
that's from it trying to run `../../gsoap/src/soapcpp2 -SC -pwsdl -I../../../gsoap-2.8/gsoap/wsdl -I../../../gsoap-2.8/gsoap/import ../../../gsoap-2.8/gsoap/wsdl/wsdl.h`
<Xagen>
so i misspoke about it being a missing directory, as that would be a binary or script of some sort then
<paulg>
Xagen, actually no - I was thinking of kergoth 's syntax issue ; sorry for confusion.
<Xagen>
no worries
<Xagen>
i did go into the devshell for that package though
<Xagen>
and i see that in the base directory that devshell drops you into for nativesdk-gsoap
<Xagen>
though it follows a different directory structure as the build
<Xagen>
but it's also in the exact location that it's looking for in build
<Xagen>
which was `.../nativesdk-gsoap/2.8.103-r0/build/gsoap/src/soapcpp2`
<Xagen>
so i'm a bit confused
<Xagen>
unless it's one of the includes that were specified
<Xagen>
all of the includes are there too
<Xagen>
thoroughly lost again
<tlwoerner>
zeddii: how are kernel modules vs built-in handled in the kernel metadata? iow if my kernel is configured without module support and a *cfg file has "CONFIG_ZRAM=m"?
<tlwoerner>
hopefully it gets "upgraded" to CONFIG_ZRAM=y (?)
LetoThe2nd has joined #yocto
<mfe>
Question: I have a build here that fails with a inode mismatch error and I'm not sure how to debug it: https://pastebin.com/RXiMtGKg
<mfe>
The first image build works, subsequent builds (after a modification) always fail
<zeddii>
tlwoerner: typically, yes it will. or you get a warning. that it didn't make it to the final .config. In particular if another =y option selects it, or a dependency means that it switches to =y. But if something is fully standalone, it may just not be in the final .config and hence the warning.
<mfe>
So far removing tmp/ and restarting the build solves the issue...
<tlwoerner>
zeddii: nice, thanks
<mfe>
wondering if this could be related to docker (i'm using crops) or the host system itself
shoragan has quit [*.net *.split]
tkoskine has quit [*.net *.split]
shoragan has joined #yocto
tkoskine has joined #yocto
florian has joined #yocto
ant__ has joined #yocto
xmn_ has joined #yocto
xmn has quit [Ping timeout: 258 seconds]
jwillikers has quit [Remote host closed the connection]
camus1 has joined #yocto
tp43_ has quit [Ping timeout: 245 seconds]
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
jwillikers has joined #yocto
tp43_ has joined #yocto
xmn_ has quit [Quit: xmn_]
xmn has joined #yocto
zyga has quit [Ping timeout: 245 seconds]
zyga-mbp has joined #yocto
xmn has quit [Ping timeout: 245 seconds]
cocoJoe has quit [Quit: Client closed]
xmn has joined #yocto
florian has quit [Ping timeout: 268 seconds]
<RP>
kergoth: oops. Those names are confusing and probably better changed anyway ;-)
obcecado has joined #yocto
<obcecado>
hi o/
<obcecado>
anyone in the mood to help a yocto newbie? thanks for your patience
<rburton>
just ask and someone might help
<obcecado>
i'm attempting to build an image for a x86 board that has 32bit grub and 64bit OS
<obcecado>
but i'm failing to find a recipe that accounts for this
<obcecado>
where should i start reading up?
<obcecado>
it's an atom cherry trail cpu
<rburton>
you might want to just mail the meta-intel list, but why a 32-bit grub?
<obcecado>
unfortunately it fails to run/boot 64bit grub
<obcecado>
there are some 3rd party scripts to modify ubuntu isos, to replace 64bit grub with 32bit, that make it bootable
<rburton>
well multilib lets you do builds like that
<rburton>
so read up on that in the manual
<obcecado>
will do, thank you for the pointer :-)
<rburton>
normal would be 64-bit but set the bootloader as lib32-grub
florian has joined #yocto
<obcecado>
i guess this is cursed hardware
<rburton>
well, yes :)
tp43_ has quit [Ping timeout: 245 seconds]
<obcecado>
it's a lattepanda board btw
prabhakarlad has quit [Quit: Client closed]
amitk_ has quit [Ping timeout: 245 seconds]
<FO3>
i dont know if this will prevent it: NON_MULTILIB_RECIPES = "grub grub-efi make-mod-scripts ovmf u-boot" in multilib.conf
<obcecado>
reading that file seems to imply that: # These recipes don't need multilib variants, the ${BPN} PROVDES/RPROVDES
<obcecado>
i guess i'll build a 32bit image for starters
xmn has quit [Ping timeout: 240 seconds]
xmn has joined #yocto
zyga-mbp has quit [Ping timeout: 248 seconds]
manuel1985 has joined #yocto
zyga-mbp has joined #yocto
aleblanc has quit [Ping timeout: 258 seconds]
<obcecado>
reading the tune-core2.inc file, it looks there is already other cpus with similar needs?
<obcecado>
eg: core2-64-x32
<obcecado>
or am i misinterpreting it?
aleblanc has joined #yocto
aleblanc has quit [Remote host closed the connection]
aleblanc has joined #yocto
aleblanc has quit [Ping timeout: 248 seconds]
davidinux has quit [Ping timeout: 248 seconds]
leon-anavi has quit [Quit: Leaving]
<rburton>
the latter :)
<rburton>
x32 is something special
<manuel1985>
JPEW: When building a raspberry pi image with oe-core + meta-raspberrypi as you said, which image does one have to build?
<obcecado>
thanks and sorry for wasting your time :-)
<manuel1985>
The images defined in meta-raspberrypi point to core-image-* ones which all do not contain X.
<rburton>
core-image-x11 is a minimal X image
<rburton>
or core-image-sato is PDA-style
<rburton>
or pull in more layers and build xfce or similar
<JPEW>
manuel1985: What image were you building before?
zyga-mbp has quit [Ping timeout: 240 seconds]
<manuel1985>
rburton: Thanks these slipped my mind. Got confused by all the locations there are images at.
zyga-mbp has joined #yocto
<manuel1985>
JPEW: One which I wrote myself and was requiring recipes-core/images/core-image-minimal.bb.
<JPEW>
manuel1985: Ah... I think that image doesn't include `kernel-modules` by default, which *might* be why it wasn't working before
<JPEW>
manuel1985: That one always gets me :)
<JPEW>
manuel1985: Anyway, you probably want core-image-weston
<manuel1985>
JPEW: Ok this didnt catch my attention. I was focusing my search on graphics related stuff (libegl, glx and stuff)
<manuel1985>
Hmm, gonna try that. Thanks.
<manuel1985>
kernel-modules is a package, right? No IMAGE_FEATURE, DISTRO_FEATURE or stuff?
<JPEW>
manuel1985: Ya. IIRC you won't get the /dev/dri/ nodes without the kernel modules, which means no graphics
<manuel1985>
Yeah these I didn't have.
<manuel1985>
I had /dev/fb0, though.
<JPEW>
Correct. Add it to IMAGE_INSTALL
xmn has quit [Ping timeout: 245 seconds]
goliath has quit [Quit: SIGSEGV]
xmn has joined #yocto
zyga-mbp has quit [Ping timeout: 268 seconds]
zyga-mbp has joined #yocto
manuel1985 has quit [Quit: Leaving]
Ad0 has quit [Ping timeout: 268 seconds]
manuel1985 has joined #yocto
Ad0 has joined #yocto
<manuel1985>
JPEW: Can't try out with kernel-modules because it seems my RPI died. wtf.
LetoThe2nd has quit [Quit: Connection closed for inactivity]
florian has quit [Ping timeout: 248 seconds]
dev1990 has quit [Quit: Konversation terminated!]
goliath has joined #yocto
dev1990 has joined #yocto
<manuel1985>
JPEW: Any idea why `oe-pkgdata-util list-pkg-files kernel-modules` prints no package contents? It prints the package name, though, and doesn't raise a "package not found" error.
<rburton>
put -r in that
<JPEW>
manuel1985: I think it's a meta package for all the actual kernel module packages
<rburton>
erm, -p
<rburton>
but no, i'm tired and i'm thinking of the firmware for some reason.
<rburton>
yes, kernel-modules is just a load of package manager depends
zyga-mbp has quit [Ping timeout: 248 seconds]
zyga-mbp has joined #yocto
bluelightning has joined #yocto
goliath has quit [Quit: SIGSEGV]
<khem>
LetoThe2nd: right now only board that would work with meta-riscv is freedom-u540 the other is/was beagleV but that board is not coming out of beta so perhaps not going to be available anytime soon. third option is hifive-unmatched which is still WIP. Best option as of now is qemuriscv32/qemuriscv64