jmiehe has quit [Read error: Connection reset by peer]
camus1 has joined #yocto
camus has quit [Ping timeout: 265 seconds]
camus1 is now known as camus
goliath has joined #yocto
mihai- is now known as mihai
GNUmoon has quit [Ping timeout: 276 seconds]
F_Adrian has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 265 seconds]
camus1 is now known as camus
goliath has quit [Quit: SIGSEGV]
goliath has joined #yocto
camus has quit [Ping timeout: 240 seconds]
camus has joined #yocto
leon-anavi has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
willo has quit [Ping timeout: 260 seconds]
GNUmoon has joined #yocto
willo has joined #yocto
rfuentess has joined #yocto
<coldspark29[m]>
Morgään
xantoz has quit [Read error: Connection reset by peer]
xantoz has joined #yocto
dev1990 has joined #yocto
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
<JosefHolzmayrThe>
yo dudX
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
mvlad has joined #yocto
tre has joined #yocto
<coldspark29[m]>
Where is the right places to make changes to the kernel defconfig? You don't touch the meta-freescale I assume, but do it in your own meta layer right?
tnovotny has joined #yocto
<JosefHolzmayrThe>
coldspark29: exactly. bbappend in your own layer
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
<RP>
rburton: sorry, getting vim fuzz :(
florian has joined #yocto
rob_w has joined #yocto
<coldspark29[m]>
<JosefHolzmayrThe> "coldspark29: exactly. bbappend..." <- So for `meta-freescale/recipes-kernel/linux/linux-imx/mx8/defconfig`, I would create a `meta-my/recipes-kernel/linux/linux-imx/mx8/defconfig.bbappend` ?
<coldspark29[m]>
From what I understand I would have to create my own defconfig and list it in a .bbappend file, but I am confused, because it is an .inc file
<coldspark29[m]>
* .bbappend file, to exchange it with the one from the vendor, but I
MauroAnjo has joined #yocto
<JosefHolzmayrThe>
the bb pulls in the inc, your append then modifies the result. thats exactly as intended.
<RP>
something in master-next is toxic and I don't know what. The autobuilder is so backed up I can even run single build tests any time soon :(
kayterina has joined #yocto
kayterina[m] has joined #yocto
<rburton>
annoying
<RP>
and the thing hasn't reproduced locally yet after an hour building. There is some other gremlin breaking my local build. Does anyone else see swig issues in gpgme?
<RP>
"core-image-sato - OK - All required tests passed" - great, doesn't reproduce :/
<RP>
and the buildbot decided to be clever and merged my requests for three different revisions into one
<RP>
it is going to be one of those days
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
heng has joined #yocto
michalkotyla has joined #yocto
michalkotyla has quit [Client Quit]
<heng>
What's the normal route to handling a machine shutdown? I want to handle a user initiated `shutdown` by sending suitable signals to the hardware. Is this done with ACPI under yocto? In which case is the solution to write a suitable ACPI driver?
<heng>
(yocto poky)
mihai has quit [Quit: Leaving]
<rburton>
heng: this is generic linux not yocto, and it really depends on your hardware and how it would normally be glued up
<heng>
rburton Ok, thanks. Does it use the normal ACPI subsystem?
<rburton>
if you;ve configured it to do that then yes
<heng>
rburton haha! naturally.
<rburton>
the standard x86-64 kernel uses acpi but you've not said what your hardware or your kernel is, so i can't say
<heng>
ARM7 (zynq)
<heng>
(apparently not)
<heng>
(ACPI I mean)
<rburton>
yeah 32-bit arm doesn't really use acpi at all
<rburton>
i note that the arch/arcm/mach-zync/ directory in the kernel doesn't have a pm_power_off implementation
<heng>
Yeah, I noticed that
<rburton>
which would explain why nothing happens
<heng>
It's kind of meaningless in general. It requires the hardware to do something, so it makes sense.
<heng>
It guess I'm trying to understand if there is a subsystem I should be using, or whether it's a kernal patch
<rburton>
you might be trying to do something the hardware can't physically do
<kanavin>
jonmason, rburton any comment? is that somehow 'obsolete'?
<heng>
Indeed, which brings me back to my question - what subsystem do I need to target with the driver
<rburton>
kanavin: depends how you define obsolete
<heng>
(I appreciate this is now outside of yocto, for which I apologise)
<kanavin>
I mean, is there something that makes it not relevant for fedora-type distros?
<rburton>
heng: your system, you define it. glue it up in the kernel so a standard shutdown runs your code, and you're sorted
<jonmason>
kanavin: more of "too much of a PITA to maintainer for each variant"
<kanavin>
they should switch to yocto :)
<heng>
thanks!
<kanavin>
crazy as it sounds I suggested exactly that for their automotive attempts
<kanavin>
RHEL just won't fly in cars
<jonmason>
because OE/YP tunes for each, we don't have their problem of needing to make a specific, single image
<RP>
kanavin: you were working on flying cars? :)
<jonmason>
being high in a car isn't a flying car
<rburton>
kanavin: i totally understand that fedora considered 32-bit arm obsolete. its a pain to natively build, the userbase for fedora was tiny, and 'one image that just works' isn't really possible
<kanavin>
right, I guess for yocto this means nothing
<rburton>
exactly
otavio_ has joined #yocto
<rburton>
RP: i propose that we drop the libtool renaming. with hosttools we can;t run the host libtool binary, and we get to drop a slew of patches which are entirely working around the rename.
otavio has quit [Ping timeout: 252 seconds]
<RP>
rburton: it probably is the right thing to do
<RP>
rburton: I have a vim patch refresh FWIW. I just don't quite understand how you didn't see the warnings :/
<rburton>
line endings got mangled?
<rburton>
i was about to ask, i can push the branch
<RP>
kanavin, rburton: I think the xauth upgrade is somehow breaking things
<rburton>
RP: huh
<rburton>
oh i wonder if i can blame devtool
<RP>
poor devtool
* JosefHolzmayrThe
headpats devtool
<jaskij[m]>
My three week staycation got confirmed yesterday, so if no one picks it up I'll do that CMake toolchain file. And some work on that dependency filtering script.
<rburton>
RP: I might have been building my workspace and not the pristine source
<RP>
rburton: I guess something to watch for in future ;-)
<rburton>
ok so why do we need to pass --tag=CC so much to libtool
<coldspark29[m]>
mckoan: The first command from your WIki tells me that my tmp directory has changed location, although it is located in the folder. I don't want to rebuild. because Chromium is taking ages. Any ideas how to circumvent this?
<coldspark29[m]>
Maybe this has something to do with Docker
<RP>
kanavin: I know, I just mention it in case you see and propose it again - we're probably going to need to debug
zpfvo has quit [Ping timeout: 265 seconds]
<RP>
kanavin: I'd ask the maintainer to help look into it but it doesn't have one
zpfvo has joined #yocto
<RP>
well, bisect said xauth but build still failing with that reverted
zpfvo has quit [Ping timeout: 265 seconds]
zpfvo has joined #yocto
<RP>
kanavin, rburton: looks like the libsdl upgrade
zpfvo has quit [Ping timeout: 265 seconds]
<kanavin>
RP: right
<mckoan>
coldspark29[m]: no clue
zpfvo has joined #yocto
<coldspark29[m]>
mckoan: Guess I will have to start from scratch
<coldspark29[m]>
Seems like bitbake doesn't find the tmp directory on your host if you have built with a Docker container. On the other hand bitbake doesn't find a terminal emulator in the container for the devshell.
<coldspark29[m]>
ERROR: OE-core's config sanity checker detected a potential misconfiguration.
<coldspark29[m]>
Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).
<coldspark29[m]>
Following is the list of potential problems / advisories:
<coldspark29[m]>
Error, TMPDIR has changed location. You need to either move it back to /home/claussenj/Workspace/Yocto-Workspace/build-vti2/tmp or delete it and rebuild
<coldspark29[m]>
mckoan: So you work with an older Ubuntu version?
<coldspark29[m]>
When I use 21.10 Bitbake complains that it is not verified
<coldspark29[m]>
Using an older version is no option for me because many Vim plugins don’t work on it.
<coldspark29[m]>
Maybe someone else here has had the same issue
<qschulz>
coldspark29[m]: just mount the directory from your docker host into the same path in your container
<qschulz>
I guess that should just do it
<qschulz>
although... removing the TMPDIR is fine, just make sure DL_DIR (downloads) and SSTATE_DIR(sstate-cache) directories are outside of it
<JPEW>
coldspark29[m]: you might want to look at pyrex. It will let you build in docker, but use your normal host vim, etc. https://github.com/garmin/pyrex
<mckoan>
coldspark29[m]: I use a native Ubuntu macibe or in case a VirtualBox one, no docker
<mckoan>
s/macibe/machine
<coldspark29[m]>
<qschulz> "coldspark29: just mount the..." <- Should do the trick for now
<coldspark29[m]>
<JPEW> "coldspark29: you might want to..." <- Thanks, will have a look. Does it work without issues?
<JPEW>
coldspark29[m]: we use it every day, tested from to to 2.1 to 3.2
<coldspark29[m]>
JPEW: So it basically forwards all bitbake commands to the container?
<JPEW>
Yes
dev1990 has quit [Quit: Konversation terminated!]
<coldspark29[m]>
Seems like it solves all the above I just mentioned
Wouter0100 has quit [Ping timeout: 252 seconds]
Wouter0100 has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
rob_w has quit [Remote host closed the connection]
<coldspark29[m]>
JPEW: Should I run the quickstart guide commands in my sources directory?
<coldspark29[m]>
Because I can't initialize the build environment that way
<coldspark29[m]>
Seems like it is expecting to find the script in PATH
<JPEW>
I don't know what your directory layout is like. If you are using poky, the first quickstart can get you started, otherwise if you have split oe-core and bitbake use the second
<coldspark29[m]>
How do I find that out?
<coldspark29[m]>
I suspect to have the standard layout
<coldspark29[m]>
s/I suspect to have the standard layout/I am assuming to have the standard layout/
<coldspark29[m]>
But not sure
sakoman has joined #yocto
<JPEW>
coldspark29[m]: Many do.... it's hard for me to "guess" though
<JPEW>
If you have a single repo with a "meta" and "bitbake" sub-directory, it's probably poky (or poky-style anyway)
<JPEW>
Other layers are usually pulled in as subdirectories (siblings of "meta") and name "meta-something" (e.g. "meta-raspberrypi")
<coldspark29[m]>
Well, in my sources folder I have a bunch of meta- folders and a poky folder
<coldspark29[m]>
So sounds like the second
<JPEW>
coldspark29[m]: Ya, it's a variant of that
<coldspark29[m]>
Would be great to add a guide to identify the layout to the Github readme
<JPEW>
coldspark29[m]: There are so many ways that's done...
<JPEW>
anyway, you want the second, just make sure that OEROOT and BITBAKEDIR are set appropriately
<coldspark29[m]>
Both guides don't work for the though
<JPEW>
in your case, OEROOT=$(pwd)/poky/meta and BITBAKEDIR=$(pwd)/poky/bitbake
<JPEW>
oops, sorry
<JPEW>
OEROOT=$(pwd)/poky
<coldspark29[m]>
Anyway, this is too complicated for me
<coldspark29[m]>
I need to get started first
<coldspark29[m]>
I am really new to Yocto
<JPEW>
coldspark29[m]: Sure. If you just want to get started, I would not bother building in a container
<coldspark29[m]>
Do I need to run this as root?
<coldspark29[m]>
I need to build in a container
<JPEW>
You cannot build as root (bitbake will not allow it)
<coldspark29[m]>
The build fails on my host
<JPEW>
coldspark29[m]: What is your host and what is the error?
<coldspark29[m]>
❯ . ./pyrex-init-build-env
<coldspark29[m]>
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/images/create?fromImage=garminpyrex%2Fubuntu-20.04-oe&tag=v1.4.1": dial unix /var/run/docker.sock: connect: permission denied
<coldspark29[m]>
Host is Ubuntu 21.10
<JPEW>
coldspark29[m]: Oh, you are still trying to build in pyrex
<coldspark29[m]>
Yes
<JPEW>
You need to setup your user so it can talk to docker
<JPEW>
usually adding it to the "docker" group, but YMMV
<coldspark29[m]>
You mean rootless docker?
<JPEW>
No
<JPEW>
normal users can user docker if they are in the correct group
<coldspark29[m]>
I am in that group already
<coldspark29[m]>
I have built all of my Android stuff in a container as well
<coldspark29[m]>
I also have to use `. ./pyrex-init-build-env`
<coldspark29[m]>
Not `. pyrex-init-build-env`
<coldspark29[m]>
and sure that OEROOT is not meta-openembedded?
<coldspark29[m]>
base meta-boundary meta-clang meta-freescale meta-freescale-distro meta-openembedded meta-qt5 poky pyrex-init-build-env
<coldspark29[m]>
Still doesn't work. Going with simple Docker now. I need to start building today
kayterina has quit [Read error: Connection reset by peer]
camus has quit [Ping timeout: 240 seconds]
camus has joined #yocto
akiCA has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
<JPEW>
coldspark29[m]: Ok. Sorry, I don't know what the hang up is
codavi has joined #yocto
<coldspark29[m]>
JPEW: No worries. Thank you for the help. I just still can't initilaize the environment
<coldspark29[m]>
First of all it doesn't find the pyrex-init-build-env
<coldspark29[m]>
I have to use `. ./pyrex-init-build-env`
<coldspark29[m]>
and then it doesn't have the elevated rights for Docker
<coldspark29[m]>
Maybe I have to read the extended guide more carefully tomorrow. The quickstart guide doesn't work for me
akiCA has quit [Ping timeout: 240 seconds]
codavi is now known as akiCA
<qschulz>
coldspark29[m]: can you start a docker container without sudo from your current user? i.e. `docker run -it alpine:latest ash`?
<qschulz>
i.e. / e.g.
<coldspark29[m]>
qschulz: Sure
<qschulz>
coldspark29[m]: also there are small differences between . and source, so maybe just try source pyrex-init-build-env (in the end, what matters is that the script is sourced, so if . already works, fine)
<coldspark29[m]>
qschulz: I know but it is annoying when there is a bunch of commands that I have to change because the dot is missing. I want to be able to copy/paste commands from guides
<qschulz>
this is the docker command that will be run, so you can start debugging from there I guess
jpuhlman_ has joined #yocto
<qschulz>
coldspark29[m]: well, it's most likely your host distribution/setup that is doing something weird :)
<coldspark29[m]>
I just deleted my whole Yocto Workspace. Will try tomorrow
<qschulz>
the . thing is not a Yocto thing so it won't help to have deleted the Yocto tmpdir
<coldspark29[m]>
I had a problem with openjdk during building. That is why delted everything
maoti__ has quit [Ping timeout: 265 seconds]
<coldspark29[m]>
And mainly because I am a noob I suppose
<coldspark29[m]>
This is going to be a rough ride. Porting a whole Android system over to Yocto and no one in the company is experienced :P
Tokamak_ has quit [Ping timeout: 268 seconds]
<coldspark29[m]>
But I shouldn't delete stuff. Rebuilding Chromium every time is not feasible
<qschulz>
coldspark29[m]: you're not rebuilding chromium every time
<coldspark29[m]>
Unless I had a Threadripper
<rburton>
fwiw . is preferred over 'source'
<coldspark29[m]>
Do you have Threadrippers?
<qschulz>
only if a dependency of Chromium has changed would Chromium be rebuilt
<qschulz>
there's sstate-cache for a reason
<coldspark29[m]>
qschulz: Well every time I change something in the Chromium configuration, I have to
<qschulz>
so if you don't remove the sstate-cache, you should be fine
<qschulz>
this has nothing to do with "delete stuff", but yes
<coldspark29[m]>
I just removed EVERYTHING
<qschulz>
but.. why? we told you to keep DL_DIR and SSTATE_DIR
<qschulz>
also, just remove chromium from your build until you have the rest figured out
<coldspark29[m]>
I thought something was broken
<coldspark29[m]>
qschulz: How?
<coldspark29[m]>
Remove it from the manifest.xml?
<coldspark29[m]>
The meta-browser layer I mean
<coldspark29[m]>
gcc
<qschulz>
some recipe(s) add chromium to their dependencies (DEPENDS, RDEPENDS, RRECOMMENDS or IMAGE_INSTALL in an image recipe for example), so just remove those recipes and/or their RDEPENDS/RRECOMMENDS/IMAGE_INSTALL
Tokamak has joined #yocto
<qschulz>
when something's broken, most of the time it's just the tmpdir that needs to be removed, but the sstate-cache and the downloads directory should be kept between builds/tries
Tyaku has joined #yocto
<coldspark29[m]>
Okay
<coldspark29[m]>
qschulz: Isn't there an easier way than removing all those recipes?
<rburton>
just remove the reference to chromium
<qschulz>
sorry, I forgot to finish the sentence "from where they're added"
<coldspark29[m]>
I tried removing it from the manifest.xml, but it still tries to build it
<rburton>
the manifest just pulls in the git repo, you'll want to rip it out of the dependency tree somehow (or build a smaller image until you get that working)
<coldspark29[m]>
rburton: Where do I find that?
<rburton>
one of the recipes you're building
<rburton>
i don't know what you're building, so i can't tell you what to edit. something depends on chromium, if you're still battling the build then removing that will save a lot of time.
<coldspark29[m]>
I have pretty much a standarrd imx8 Yocto
<coldspark29[m]>
We have just made little modifications in our layer
rob_w has joined #yocto
adrian__ has joined #yocto
<qschulz>
coldspark29[m]: there's no such thing as a standard imx8 Yocto :)
zpfvo has quit [Ping timeout: 240 seconds]
<coldspark29[m]>
-.-
zpfvo has joined #yocto
<qschulz>
I really mean it, the imx8 is not supported in the layers that makes the Yocto Project (more or less poky)
<qschulz>
so you necessarily need more layers, and for imx8 you probably have multiple choices, one being meta-imx and another meta-freescale, and probably also other vendor layers
<JosefHolzmayrThe>
why would a simple core-image-minimal or core-image-full-cmdline build pull in chromium? i'm pretty sure it doesn't. start small, add on top. bonus: you get much shorter build times.
<coldspark29[m]>
Guess it is not simple then. I can't start completely from scratch though.
<coldspark29[m]>
Because I am the new guy and I am not going to revert all the progress that may colleagues have already made
<coldspark29[m]>
Just to remove Chromium...
<JosefHolzmayrThe>
then ask your colleagues.
<JosefHolzmayrThe>
but seriously, demanding support on IRC for "I just want to, because it is like that and I'm not gonna understand why" is a really bad starting point.
camus has quit [Ping timeout: 240 seconds]
camus has joined #yocto
<coldspark29[m]>
I get your point. I should read the basics again.
<JosefHolzmayrThe>
no. if there are colleagues who set this up, then get to their desk and have it explain to you.
<qschulz>
coldspark29[m]: Yocto has a steep learning curve, if you try to hack some things together, it'll be painful and will bring you down
<JosefHolzmayrThe>
there might be reasons that are not obvious. so before wasting time and digging useless resources - just ask people.
<coldspark29[m]>
They don't know that much really
<qschulz>
so try small to understand the concepts, it does not have to be a direct application of the project you're working on
<coldspark29[m]>
qschulz: Yeah that is why I think I should start with the basics
<qschulz>
JosefHolzmayrThe's video tutorials on Yocto Project youtube channel should help with making the basic concepts a bit clearer but I really think that with Yocto you need to practice and do in order to understand how things are workin
tnovotny has quit [Quit: Leaving]
<JosefHolzmayrThe>
rule of thumb: whenever somebody says "I have this bloated image and I just want to remove XYZ without understanding the reasoning, its just my will because I demand it", then its wrnog and only leading to more trouble.
mattsm has joined #yocto
rob_w has quit [Remote host closed the connection]
<JosefHolzmayrThe>
this generic situation is so common that it even made it to my presentation at YPS, as the only one newbie question.
<coldspark29[m]>
I didn't want to remove anything in the first place. That was just suggested to me here
<coldspark29[m]>
Josef Holzmayr (TheYoctoJester): What video tutorial do you suggest for a beginner?
<vd>
there's no issues in having an override specified twice, right? e.g. DISTROOVERRIDES = "foo:foo"?
leon-anavi has quit [Remote host closed the connection]
dj has joined #yocto
dj is now known as Guest4970
zpfvo has quit [Ping timeout: 252 seconds]
<Guest4970>
i just want to confirm that for each repo/project I would name my project as meta-myproject inside poky? doesn't having multiple projects mess with `source oe-init...`?
<kernelsandals>
Hi I'm wondering if someone can point me in the right direction here. I've run into an issue trying to build the chromium-ozone-wayland browser for an imx8MP platform. The error I'm getting just says FAILED: yocto_native/brotli and a clang-10 notice that the linker command failed, use -v to see invocation. I already have -v in my BUILD_LDFLAGS and HOST_LDFLAGS but have not been able to determine
<kernelsandals>
what actual error the linker is complaining about
troth has joined #yocto
<kernelsandals>
I had a similar issue a while back due to this being a Centos7 build system and this recipe not finding -latomic, but that is resolved by passing a valid latomic path to BUILD_LDFLAGS
Guest96 has joined #yocto
<kernelsandals>
This build was working fine until I did a repo sync, which admittedly I hadn't done for quite some time