Saur has quit [Read error: Connection reset by peer]
odra has joined #yocto
Saur has joined #yocto
sakoman has quit [Quit: Leaving.]
davidinux has quit [Ping timeout: 240 seconds]
davidinux has joined #yocto
odra_ has joined #yocto
odra has quit [Read error: Connection reset by peer]
starblue has quit [Ping timeout: 265 seconds]
starblue has joined #yocto
<khem>
paulg: yeah, I feel annoyed too, if it gives you any comfort, I get clang to rebuild too 🙂 which is good 1+ hrs just for toolchain, I think using locked sstate might be good idea to mature
odra_ has quit [Quit: Leaving]
xmn has quit [Ping timeout: 240 seconds]
sakoman has joined #yocto
odra has joined #yocto
odra_ has joined #yocto
odra has quit [Read error: Connection reset by peer]
<jclsn>
It is checked if they are in the work directory, but I don't understand how I would provide my own keys
<jclsn>
I mean I wouldn't want the recipe to generate new keys every time if I have several boards
<jclsn>
Ah maybe I could do a do_compile:prepend() and cp the keys to that location
zpfvo has quit [Ping timeout: 265 seconds]
bps2 has joined #yocto
zpfvo has joined #yocto
<jbo>
Hey guys, how exactly can I find out which DTS is ultimately being used?
<rburton>
paulg: yes that's target gcc and almost certainly because you have ptest enabled and elfutils in your build. see my "why is my build so slow?!" presentation :) Turn off ptest if you don't use it. Personally, I just turn ptest off for elfutils :)
d-s-e has joined #yocto
xmn has joined #yocto
<mckoan>
jbo: in your machine file there is KERNEL_DEVICETREE variable, then the bootloader have to know what to do
camus has quit [Ping timeout: 240 seconds]
zpfvo has quit [Ping timeout: 240 seconds]
<jbo>
thanks!
Thorn has quit [Ping timeout: 248 seconds]
<jbo>
I'm trying to include GPM (general purpose mouse) in my image. I added "gpm" to my IMAGE_INSTALL:append. However, bitbake complains that nothing provides 'gpm'.
<rburton>
pro tip: layers.openembedded.org to find recipes
ptsneves has joined #yocto
<jbo>
rburton, just checked the git repo remote and the one you linked is indeed the one I'm using
<jbo>
also thanks for pointing at layers.openembedded.org! that is useful!
<jbo>
currently trying all the different mouse types (-t parameter of gpm) but nothing works. always logging "Error in read()ing first: Invalid argument" :<
Thorn has quit [Ping timeout: 240 seconds]
zpfvo has quit [Ping timeout: 265 seconds]
<jbo>
evtest seems to indicate a working mouse tho.
<rburton>
does gpm even work with modern systems? I've not used it for literally decades, but I see the list of supported mouse types doesn't include "evdev"
<jbo>
I've no idea - doesn't seem like it so far :D
zpfvo has joined #yocto
<jbo>
I'm trying to make a demo with a minimal GUI which directly tapps the framebuffer (no X, no Wayland, ...) which overall works. but there's no mouse cursor :D
<jbo>
is there a more modern replacement for gpm?
<rburton>
your minimal GUI should just use evdev and draw a pointer etc
<jbo>
can't argue with that
<rburton>
basically, use a proper toolkit :)
Thorn has joined #yocto
seninha has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
kpo_ has joined #yocto
Thorn_ has joined #yocto
Thorn has quit [Ping timeout: 246 seconds]
camus has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
d-s-e has joined #yocto
kaitsh has joined #yocto
d-s-e has quit [Ping timeout: 240 seconds]
d-s-e has joined #yocto
Algotech has quit [Ping timeout: 265 seconds]
Algotech has joined #yocto
krissmaster has quit [Remote host closed the connection]
<jbo>
so far I have been using existing machine configurations for a dev-kit despite having custom hardware. I think it's time to create a custom machine config. I'm looking at the corresponding documentaiton right now. However, I'm not yet in the clear as to whether I can start by just declaring the minimal stuff required and then include/reference/inherit the existing dev-kit machine config?
<rburton>
the easiest thing would likely be to make a minimal one and then adds bits as you need them. it depends on the bsp as to how modular they made it...
<jbo>
although I guess in this case I just keep using that as that is for a SoM. For another project it might make more sense as there the machine config in use is for a particular EVK rather than just the SOM.
<jbo>
in case of the imx8mm I'd just like to drop out all the wifi & bluetooth stuff
<rburton>
if the bsp is designed right, just drop those from DISTRO_FEATURES
<jbo>
alright, thanks for the hint. I'll look into DISTRO_FEATURES. I haven't created a custom distro yet. Just using poky.
<rburton>
if you're doing something serious and not just playing, make a new distro
<rburton>
poky is an example and for qa. i expect you don't want bluetooth, or vulkan, or NFC
<rburton>
poky has all of those turned on
<jbo>
until now I was playing around to familiarize myself with yocto. now I am starting to go serious.
<jbo>
so I guess now is the time to look into creating a distro. scary
<rburton>
its not :)
<jbo>
I've only done stimple stuff like IMAGE_INSTALL:append so far. and custom kernel configs and custom DTS patches.
<jbo>
how does a distro relate to/with an image I'm building via bitbake <image_name>? So far I played around by building core-image-minimal, core-image-base and core-image-weston. I assume that the image "consumes" the distro? i.e. I will still be able to build different distros?
vladest has quit [Ping timeout: 240 seconds]
<rburton>
yeah, distro is policy, you can change distros and still build the same images
<jbo>
alright
<jbo>
so the documentation I just linked mentions that the distro is selected in local.conf. However, that is in the build directory. I do not yet understand how one creates something that can actually be shared with other developers in a way that they don't have to manually add all the layers and making changes to local.conf.
<jbo>
how does that work? I would not want my collegues having to do the same work each time. what have I currently not seen yet? :D
<rburton>
https://github.com/rossburton/customdistro most likely needs updating for latest releases but it's super trivial for your distro layer to provide its own local.conf template which sets the right distro
<rburton>
like how when you oe-init-build-env in a poky tree your local.conf says DISTRO=poky
<rburton>
if you use oe-core+bitbake directly, you don't get that
<jbo>
I see. And how would that work with regards of adding layers? Currently, I cloned all the repos, did the oe-init-build-env and then used bitbake-layers add-layer to add the custom layer(s). Can that be automated?
kscherer has joined #yocto
<jbo>
i.e. I had to add more layers than just my custom layer. can I somehow tell my custom layer that it "requires" other layers such as meta-arm etc?
<rburton>
there is basic tooling inside bitbake now, or use kas, or git submodules
<rburton>
that customdistro thing uses submodules
<rburton>
for our CI we use kas
<jbo>
that part I have done (via git submodules). but when creating the build directory the first time I still have to modify the build/conf/bblayers.conf
<jbo>
alright - plenty of stuff to dig into - thank you! :)
<rburton>
basically local.conf and bblayers.conf are generated at init time from templates. you can provide those templates.
mckoan is now known as mckoan|away
<jbo>
those templates being *.sample?
<rburton>
yes
<rburton>
you'll see them in poky's repo too
<jbo>
hmm... why exactly are you shipping both *.conf and *.conf.sample if the "real" one is being generated from the sample?
<jbo>
never mind.
<jbo>
adding the layers automatically worked :)
<jbo>
pre-populating local.conf worked too! excellent! thank you for your help :)
vladest has joined #yocto
<jbo>
actualy... I mistakenly edited the local.conf.sample & bblayers.conf.sample in the poky directory - lol. I corrected the mistake. However, how do I tell "source oe-init-build-env" to use the stuff from my meta-custom to populate conf/ ?
florian_kc has joined #yocto
<rburton>
easiest way is to provide your own setup instead of oe-init-build-env
<paulg>
rburton, RP - I typically start with the oe-init autogen'd conf/local.conf and then mash on it from there. I'm guessing so do a lot of people.
<rburton>
yeah, and poky turns on a load of stuff for testing purposes
<paulg>
And if I'm getting screwed by ptests being enabled, I guess it comes from that.
<rburton>
if build time is a bother _and_ you don't run them, definitely disable them. the extra deps are quite invasive in places.
<jbo>
rburton, thanks, I'll try to fix my setup/layout.
<paulg>
I will definitely look into it for the hideously slow/old junk at home.
<jbo>
basically what I did is having a project directory. in there I have several git submodules for the various meta-* layers as well as poky/ I assume that I don't want to have poky/ anymore but customdistro/ instead.
<rburton>
yes, you can ditch poky/ but you'll need to replace it with oe-core and bitbake
<RP>
paulg: we enable ptests by default else we just get patches which break the all over the place but there is a cost to it
<jbo>
I've been doing this all wrong - thanks for showing me the way!
<jbo>
when I started with yocto I was under the assumption that poky IS yocto *facepalm*
<paulg>
jbo, don't feel bad - there is definitely room for improvement in the communication dep't around poky/yocto/oe and the roles of each.
<jbo>
oh, not feeling bad - also not blaming the docs. just the usual stuff when embarking with a completely new environment/ecosystem
<jbo>
so looking at my previous bitbake output it seems to use version 2.0.0. However, now that I will include bitbake as a git submodule, I see that there is a 2.4 branch - should I be using that instead?
<Entei[m]>
Does TUNE_CCARGS unconditionally apply to all recipes being baked?
<rburton>
Entei[m]: following variable references in bitbake.conf it ends up in CC, so you'd certainly hope so
<jbo>
nothing more fun than a version inter-dependency matrix :D
agrue has quit [Ping timeout: 268 seconds]
agrue has joined #yocto
odra_ has quit [Quit: Leaving]
sakoman has joined #yocto
<jbo>
given that I already ran into the issue of assuming that poky is yocto, let's better ask now: what exactly is "kirkstone"? Is that a particular yocto version/release?
<qschulz>
jbo: it's the release name for the 4.0.x branch of Yocto/OpenEmbedded-Core
rob_w has quit [Remote host closed the connection]
<jbo>
that I understand. but what does it "consist of"? what does it "include"? for example, poky is unrelated to the yocto/oe-core release?
d-s-e has quit [Ping timeout: 240 seconds]
d-s-e has joined #yocto
<qschulz>
that's probably a task for LetoThe2nd so I won't say wrong things
<qschulz>
poky is a git repo that contains openembedded-core, bitbake and the yocto-docs git repository into one
<qschulz>
it's also the name of a distribution that is used for buildbots to check that things are still compiling well
<jbo>
based on that statement and the helpful resources that rburton linked earlier I assume that anybody doing something seirous would not use poky at all - is that correct?
<tomzy_0[m]>
Hello, how to work with Pseudo Abort errors? https://wiki.yoctoproject.org/wiki/Pseudo_Abort IIUC they may happened when something is deleting a file from WORKDIR of given recipe outside of that recipe context, so when we rebuild that recipe the Pseudo Abort may happen?
<qschulz>
jbo: that's what's recommended indeed, not everyone follows this advice though :)
<jbo>
heh :)
<jbo>
once my work is done somebody has to get all of this thorugh several audits, FDA approval etc so I assume I safe those guys downstream a lot of headaches by doing things properly from the get-go of the prototyping phase.
<jbo>
at least now I have learned to just have a look at the poky files to figure out how things are supposed to come together - that is plenty helpful!
jetm has joined #yocto
<dwagenk>
Hello. Does anyone have a good idea for the transistion psplash -> weston -> application ? I'm in a kirkstone based project using systemd as init manager.
<dwagenk>
psplash-systemd explicitely sends a "QUIT" command to psplash once systemd reports a progress of 100%. But it terminates long before that, once weston starts loading.
<JPEW>
dwagenk: We run weston as a socket-activated service with the fullscreen shell (kiosk shell would work also) in systemd; this means that the splash screen stays up until our main application opens the socket to talk to weston, at which point system starts up weston
<JPEW>
This minimize the amount of blank screen time between the splash screen and our application
<JPEW>
IIRC I upstreamed support for this to kirkstone.....
<dwagenk>
similar setup here, the application triggers weston through teh socket, the weston.service unit is not enabled, so it only gets started through the socket.
<dwagenk>
I can try switching weston-shells around (currently it's the default desktop-shell) and see if it improves the situation.
<JPEW>
Ya, fullscreen shell works well, but your application has to have special handling to deal with it. kiosk shell is the more modern replacement; it has the same idea (run a single application full screen), but looks more like a desktop shell so applications don't need special handling to use it
<dwagenk>
the screen-blank time after the splashscreen disappears is longer than the duration of the splashscreen being shown on screen (I haven't done any initramfs or other optimizations yet to show it earlier).
<JPEW>
Ah
<JPEW>
We throw up the splash screen in the boot loader
<jbo>
hmm... now that I fixed my overal yocto layout/structure bitbake cannot fetch something from toradex:
<jbo>
Bitbake Fetcher Error: FetchError('Unable to fetch URL from any source.', 'git://git.toradex.com/linux-toradex.git;protocol=https;branch=toradex_5.15-2.1.x-imx;name=machine')
<jbo>
how do I investigate this?
<jbo>
is that name=machine in there even legit?
<JPEW>
jbo: That just gives it a name for bitbake to use; it shouldn't affect the actual fetch IIRC
d-s-e has quit [Ping timeout: 240 seconds]
d-s-e has joined #yocto
goliath has quit [Quit: SIGSEGV]
<JPEW>
job: i.e. if you have multiple git repos in SRC_URI, you need to distinguish them
<dwagenk>
On a different system (dunfell + sysVinit) I've used a weston + desktop-shell + application setup before. It was far easier there, since weston was started on a different tty via the openvt command in the weston-launch script. Removing the --switch argument from that script led to weston starting & preloading on an inactive VT. once the application signaled it was ready I could just run chvt to switch to the tty with weston and the application.
<jbo>
JPEW, well, all I did was adding the meta-toradex-* layers as git submodules. I haven't touched anything INSIDE of those layers.
<dwagenk>
I'm trying to get a similarly smooth transition on the more modern stack, but it seems the weston.service and/or systemd-logind don't have a way to start weston on a VT in the background.
<JPEW>
dwagenk: Ya, I'm not sure
<dwagenk>
I'll try if using the fullscreen or kiosk shell bring notable improvements.
<JPEW>
dwagenk: If you figure it out, I'd be curious to know
jetm has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
seninha has quit [Remote host closed the connection]
<jbo>
JPEW, I just re-ran the build command a couple of times and now it seems fine. not sure whether it was infrastructure problems on Toradex's sinde
<jbo>
how do I correctly add to DISTRO_FEATURES? is it with += or with DISTRO_FEATURES:append ?
thomasd13 has quit [Ping timeout: 268 seconds]
<rburton>
jbo: if its _your_ distro then = :)
dgriego has quit [Quit: Bye]
<rburton>
otherwise i'd use append as iirc poky does ?=
<jbo>
aye. and when I want to have DISTOR_FEATURES depending on the image that I'm building? can I do something like DISTRO_FEATURES:appaned:core-image-base = "" or is that not how it works?
LocutusOfBorg has quit [Ping timeout: 248 seconds]
tgamblin has quit [Remote host closed the connection]
<rburton>
no
<rburton>
(that's not how it works)
jetm has quit [Ping timeout: 240 seconds]
jetm has joined #yocto
<khem>
DISTRO overarches on IMAGE iow you build images based on distro
LocutusOfBorg has joined #yocto
<jbo>
aye, thanks!
<jbo>
managed to have a bootable/runnable image with a custom distro :)
<jbo>
thanks for all your help & patience guys - it's greatly appreciated!
tgamblin has joined #yocto
Thorn_ has quit [Ping timeout: 240 seconds]
Thorn has joined #yocto
bps2 has joined #yocto
ptsneves has quit [Ping timeout: 248 seconds]
rfuentess has quit [Remote host closed the connection]
<duncan^>
I have EXTRA_USERS_PARAMS set up, which sets a password for root. How do I ensure that any changes to that password end up in the final rootfs? Is there a recipe/step shorthand for bitbake which will update this and produce a new image?
<duncan^>
A related question would be, is there an ideal way to rebuild a package and ensure inclusion in a new, final image?
gsalazar has quit [Ping timeout: 240 seconds]
Thorn has joined #yocto
gsalazar has joined #yocto
kpo_ has joined #yocto
kpo_ has quit [Ping timeout: 248 seconds]
gsalazar has quit [Ping timeout: 265 seconds]
goliath has quit [Quit: SIGSEGV]
leon-anavi has quit [Remote host closed the connection]
<rburton>
If you changed a recipe and that recipe produces a package that is in your image, bitbaking the image will rebuild that recipe and then the image
bryanb has quit [Remote host closed the connection]
<abelloni>
mingw still fails too: winuser.h: No such file or directory
u4ia has quit [Quit: WeeChat 3.8]
Thorn has quit [Ping timeout: 264 seconds]
kaitsh has quit [Quit: WeeChat 3.7.1]
frieder has quit [Remote host closed the connection]
<duncan^>
rburton: thanks.
BWhitten has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
gsalazar has joined #yocto
alessioigor has quit [Client Quit]
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
<jbo>
is there some high-level guide on how to get started with creating a custom distro? I already set everything up to "have" a custom distro thanks to rburton but I kind of lack some guidance on where to go from here. i.e. how do I figure out what goes into a distro, what I might want, what I might not want etc?
florian_kc has joined #yocto
BWhitten has quit [Ping timeout: 264 seconds]
seninha has joined #yocto
BWhitten has joined #yocto
sakoman has quit [Ping timeout: 246 seconds]
Guest68 has joined #yocto
Guest68 has quit [Client Quit]
sakoman has joined #yocto
gsalazar has quit [Ping timeout: 256 seconds]
BWhitten has quit [Ping timeout: 268 seconds]
seninha has quit [Ping timeout: 268 seconds]
kscherer has quit [Quit: Konversation terminated!]