jwillikers has quit [Remote host closed the connection]
Guest24 has joined #yocto
Guest24 has quit [Client Quit]
arlen has joined #yocto
wooosaii has joined #yocto
wooosaiii has quit [Ping timeout: 252 seconds]
davidinux has joined #yocto
pgowda has joined #yocto
Vonter has quit [Ping timeout: 240 seconds]
kanavin_ has joined #yocto
kanavin has quit [Read error: Connection reset by peer]
rfuentess has joined #yocto
zibri has quit [*.net *.split]
ykrons_ has quit [*.net *.split]
mcfrisk has quit [*.net *.split]
georgem has quit [*.net *.split]
woky has quit [*.net *.split]
zibri has joined #yocto
mcfrisk has joined #yocto
georgem has joined #yocto
ykrons_ has joined #yocto
woky has joined #yocto
tgamblin has quit [*.net *.split]
OutBackDingo has quit [*.net *.split]
ldts has quit [*.net *.split]
nsbdfl has quit [*.net *.split]
Shaun has quit [*.net *.split]
thekappe has quit [*.net *.split]
madisox has quit [*.net *.split]
Tartarus has quit [*.net *.split]
frosteyes has quit [*.net *.split]
override_ has quit [*.net *.split]
dv_ has quit [*.net *.split]
jpnurmi has quit [*.net *.split]
ldts has joined #yocto
Shaun has joined #yocto
OutBackDingo has joined #yocto
Shaun has quit [Changing host]
Shaun has joined #yocto
thekappe has joined #yocto
madisox has joined #yocto
dv_ has joined #yocto
frosteyes has joined #yocto
Tartarus has joined #yocto
tgamblin has joined #yocto
jpnurmi has joined #yocto
Sion has joined #yocto
override_ has joined #yocto
ThomasD13 has joined #yocto
goliath has joined #yocto
saYco[m] has joined #yocto
Vonter has joined #yocto
<JosefHolzmayrThe>
yo dudX
<manuel_>
JosefHolzmayrThe y0
manuel_ has quit [Quit: Leaving]
mckoan|away is now known as mckoan
<mckoan>
good morning
<Sion>
Good morning.
leon-anavi has joined #yocto
<Sion>
Hello everyone, I'm fairly new with Yocto (love it atm). I do have a question regarding the tested distribution list, I'm currently using Debian Bullseye in combination with the latest hardknott and I don't see any immidiate issues but is the Yocto team currently testing Debian 11 as well?
<JosefHolzmayrThe>
Sion: i have no definitive statement on that, but i'm pretty sure it will get into the autobuilder testing in some not-too-distant future.
leon-anavi has quit [Remote host closed the connection]
leon-anavi has joined #yocto
<Sion>
Ok, thanks for the quick reply.
goliath has quit [Quit: SIGSEGV]
fleg has joined #yocto
xmn has quit [Ping timeout: 265 seconds]
zpfvo has joined #yocto
oobitots has joined #yocto
<JosefHolzmayrThe>
np
frieder has joined #yocto
fbre has joined #yocto
<RP>
Sion: it isn't officially tested, no. It should work ok though and we likely will add testing for it soon
tnovotny has joined #yocto
goliath has joined #yocto
<JosefHolzmayrThe>
(stupid) question. does the adduser mechanism require something specific in the recipe?
<JosefHolzmayrThe>
erm, image?
<JosefHolzmayrThe>
specifically, does it need useradd/groupadd to be present?
<fbre>
(replace with your account names and passwords)
<JosefHolzmayrThe>
fbre: thanks... but i guess in my case the problem is not the metadata per se, but the image generation.
florian has joined #yocto
camus has quit [Ping timeout: 265 seconds]
camus has joined #yocto
<fbre>
JosefHolzmayrThe: I did not install specific useradd/groupadd stuff for the account which runs the image generation
<JosefHolzmayrThe>
fbre: no, but i guess that your image brings those and therefore they at least end up in the sysroot, right?
<fbre>
JosefHolzmayrThe: It's not an account which needs root rights
<JosefHolzmayrThe>
fbre: no, thats not what i'm talking about.
<JosefHolzmayrThe>
anyways, i'll give your approach a spin and check if there are different effects.
<JosefHolzmayrThe>
nope, perfectly the same.
<fbre>
JosefHolzmayrThe: Which error does happen?
<JosefHolzmayrThe>
fbre: i con't copy it out at the moment, but upon inspection there is no useradd/usermod in the -native sysroot. hence, it fails. so i guess my real question is: what form of dependency do i need for that tool to show up.
<fbre>
JosefHolzmayrThe: I don't know what you mean with "in the -native sysroot"...
<JosefHolzmayrThe>
fbre: your EXTRA_USERS_PARAMS needs the usermod command to be available. unless specific actions are taken, my understanding is that it will be taken from the -native sysroot for the recipe in question (in this case, the image)
<JosefHolzmayrThe>
fbre: and if the command is not there, it cannot be executed.
<fbre>
What is a "sysroot" and what is its property "-native"
<JosefHolzmayrThe>
fbre: sysroots are the environments that are created per recipe, basically from the dependencies. and the -native incarnation is the one thats meant to run during the build. no problem, i know its a complicated problem.
mihai has quit [Quit: Leaving]
<JosefHolzmayrThe>
qschulz: looks like shadow should provide it.
<JosefHolzmayrThe>
and as it inherits useradd, i'd naively expect it to pull in all things needed for... "adding users" :)
<RP>
JosefHolzmayrThe: I think I'm misreading the above, I thought you mean the user/group wasn't in the native sysroot. You're right that the tools should be added
<JosefHolzmayrThe>
RP: exactly, but it seems that this is not the case.
<RP>
JosefHolzmayrThe: for your demo recipe, you could put a chown call in the do_install
<JosefHolzmayrThe>
RP: to get rid of the dummy?
<qschulz>
JosefHolzmayrThe: also, FILES:${PN} :)
<RP>
JosefHolzmayrThe: no, just that you're not using the user/group you're creating anywhere
<JosefHolzmayrThe>
RP: lemme try.
<RP>
JosefHolzmayrThe: it won't change anything much but it would fail if there was an issue
<JosefHolzmayrThe>
RP: yeah thought so.
<JosefHolzmayrThe>
why doesn't FILES_${PN} err out on parsing?
<RP>
JosefHolzmayrThe: it can't know that is an override. It only errors on "_append" which it knows is bad
<JosefHolzmayrThe>
ah.
<JosefHolzmayrThe>
but DEPENDing on neither shadow-native nor shadow-sysroot seem to give me the commands
<JosefHolzmayrThe>
wCPO: whenever you want to run something during build time.
<wCPO>
JosefHolzmayrThe: Make sense, but why does it have libtpm-native then?
<JosefHolzmayrThe>
wCPO: no idea, look at the recipe to see what it needs. it might also be something that its build process relies on inside.
camus1 has joined #yocto
<wCPO>
JosefHolzmayrThe: I will and I'm currently trying to understand why it is there, thanks for explanation :)
<JosefHolzmayrThe>
have fun
<wCPO>
"fun" :)
<qschulz>
remove it and you shall see where it fails :)
camus has quit [Ping timeout: 265 seconds]
camus1 is now known as camus
<wCPO>
qschulz: it doesn't fail, then why I'm confused
<wCPO>
that*
<wCPO>
but I also updated the recipe to 0.6.1, maybe I should try the current version first
davidinux has joined #yocto
<RP>
wCPO: sometimes these things persist when they're no longer needed
<wCPO>
RP: yep, I'm gonna CC the guy who updated it in the past when I submit the patch, maybe he know
<sveinse>
If I specify "bitbake -k packagegroup-something package-index" will a) package-index be run even if packagegroup-something fails and b) will it execute last?
<rburton>
yes, no
<sveinse>
ok, thanks
<rburton>
(they'll execute in parallel)
<sveinse>
package-index on its own invocation step then, got it
<sveinse>
Yeah, the use case is that we're building to a packagefeed, but occational not every package compiles successfully, so in order to have a valid package feed, I'd like to update the repo I've got
<sveinse>
Normally bitbake packagegroup-x does this if and only if it completely succeeds
<rburton>
i had a patch that would run package-index in the closing stages of the build so you could always have an up to date feed, but i appear to have lost it
<RP>
rburton: you've lost it? :)
<rburton>
i lost it long ago
<RP>
rburton: I suspect we all did...
thekappe has quit [Quit: WeeChat 1.9.1]
<RP>
Makefile:DIST_DIR := $(shell mktemp -d /tmp/glew.XXXXXX)/$(DIST_NAME) seems a little antisocial
<JosefHolzmayrThe>
"of all the things that i have lost, i miss my mind the most"
<RP>
and we never actually use that
* qschulz
laughs at the timing of RP and JosefHolzmayrThe messages :D
<JosefHolzmayrThe>
qschulz: me too.
<JosefHolzmayrThe>
great minds think alike, they say.
<sveinse>
Is there a yocto/bb-way of disabling a systemd service in a ROOTFS_POSTPROCESS step? For those services that has been installed with systemd.bbclass and have a system-preset/98-*.preset entry
thekappe has joined #yocto
<sveinse>
I'm not sure how the preset logic actually work. Something in (yocto) first time startup activates the presets and thus enables/disables these services?
<qschulz>
to be done in the recipe providing the systemd service
<sveinse>
qschulz: Yes. And say the bb enables a service via these mechanisms, but then the image wants the service disabled. Whats the right way of doing that?
<qschulz>
I assume proper way would be a bbappend for that bb, or a distro. For the hackish way, looking at how it is done by the systemd class and call the same things from within the rootfs might do it
<sveinse>
Is .bb the right spot? I mean the recipe/package might be correct, but multiple images might want different enable/disables. Then I'd need a separate bbappend for each of those image variants, right?
<qschulz>
that's policy and policy is what the distro is responsible for
<qschulz>
otherwise you can always try to run `systemctl disable <service name>` in your ROOTFS_POSTPROCESS_CMD but it does not feel super right
<jaskij[m]>
Does anyone have a link or something with arguments I could use to allow my boss to open source my recipes?
<RP>
jaskij[m]: I'm not sure we have anything written into the docs. michaelo, do you know anything?
<rburton>
jaskij[m]: if they're recipes for relatively common software then the best argument is that other people will test/maintain. if you get a recipe into meta-oe for example then other will also help keep it up to date
leon-anavi has joined #yocto
camus has quit [Ping timeout: 245 seconds]
camus has joined #yocto
<jaskij[m]>
<rburton> "jaskij: if they're recipes for..." <- That's the common one, although I'm not sure how effective this would be in my case. Something to think on.
<jaskij[m]>
This is probably the first OSS project I honestly want to contribute to. Gotta take a look at the tracker when I've got some time.
agners has quit [Ping timeout: 252 seconds]
wwilly has quit [Ping timeout: 252 seconds]
agners has joined #yocto
etam[m] has joined #yocto
zyga-mbp has joined #yocto
manuel1985 has joined #yocto
<manuel1985>
Did you guys manage to run qemux86-64 with graphics acceleration? I'm building my wayland-based project for raspi4 and qemu. On raspi it runs smooth, but on qemu it's a disaster.
<manuel1985>
Doing runqemu with kvm, but guess that doesn't help anything w.r.t. graphics.
etam has joined #yocto
etam has quit [Quit: Konversation terminated!]
xmn has joined #yocto
agners has quit [Ping timeout: 252 seconds]
agners has joined #yocto
Vonter has quit [Ping timeout: 265 seconds]
Vonter has joined #yocto
<sveinse>
qschulz: I see. Under the yocto paradigm, a distro handles policy, that all good. It would then imply that you'd need multiple distros to make different policies, or startup policies, like in this case, wouldn't it? Doesn't that make it, uhm, a big machine for an image variant? Or is that how yocto distros are?
<sveinse>
Not arguing, only trying to understand
GillesM has joined #yocto
GillesM has quit [Quit: Leaving]
xmn has quit [Ping timeout: 265 seconds]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jaskij[m]>
if I'm looking right, it somehow goes through `PACKAGECONFIG` variable flags and uses the values of the flags that are listed in the base variable?
<jaskij[m]>
is this normal, or is this something that comes from one of the classes inherited?
angolini has joined #yocto
<jaskij[m]>
uh, guess this shows how I only read the manual in small parts
tgamblin has quit [Quit: Leaving]
tgamblin has joined #yocto
<qschulz>
this is the standard mechanism
<jaskij[m]>
It is, but I went reading about varflags instead of PACKAGECONFIG, and it threw me for a loop.
<Saur>
jaskij[m]: Well, varflags is a standard mechanism. How they are used is up to the classes, however. E.g., support for PACKAGECONFIG is implemented in meta/classes/base.bbclass.
<jaskij[m]>
yeah, I found that
<jaskij[m]>
just that I was reading the BitBake manual, not looking specifically at PACKAGECONFIG, is all
wwilly has joined #yocto
wwilly_ has joined #yocto
wwilly has quit [Ping timeout: 252 seconds]
wwilly_ is now known as wwilly
kiran has joined #yocto
yates has quit [Remote host closed the connection]
<sveinse>
While on systemd: Has anyone made an overview of the most common systemd targets for use in yocto? Or is our systemd usage so vanilla systemd that its really a systemd default question?
<sveinse>
systemd targets = system policy = distro = so in poky I suppose
<perdmann>
bb.process.NotFoundError: Execution of 'git rev-parse --abbrev-ref HEAD' failed: command not found
<perdmann>
But git is installed
<yates>
is there a verbatim log of a bitbake build stashed somewhere, perhaps in build/tmp? i'm not referring to the individual build/tmp/.../temp log.xyz logs
<yates>
there are some qa warnings i received on a previous build that i'm trying to review and i've since rebooted so the terminal containing them is gone
<yates>
i also occasionally want to see the last value N that was reported as "N tasks of M completed" in an unsuccessful build, so i know how far along it got. is that data stored in a log somwhere?
rfuentess has joined #yocto
Schlumpf has quit [Quit: Client closed]
<yates>
perdmann: perhaps something in the build is hosing your path
<yates>
?
<perdmann>
hosing?
<yates>
ruining
<yates>
what, you never lived in San Jose, CA circa the 80s? :)
<perdmann>
How can i find out of it ruins something?
arr has joined #yocto
<perdmann>
yates: i was born 86 :-)
<yates>
perdmann: one way i can think of is to cd to the appropriate .../temp directory, find out the run.do_whatever is being run, and hack it to spit out the path
<yates>
(if it's a bash script. python run.do_xyz scripts are not so easy)
<yates>
youngster!
<perdmann>
yates: haha, feels good that somebody says this to me ;-)
<yates>
enjoy it while it lasts... ;)
<yates>
ps: subtract 29 from your birth year..
<perdmann>
senior developer :-D
agners has quit [Quit: WeeChat 3.2.1]
agners has joined #yocto
<yates>
:)
<perdmann>
yates: i dont have any run. files...
<yates>
i missed your entire message. what is the entire message?
<yates>
perdmann: is this the first time you've tried to build a yocto project on that system?
<yates>
have you successfully built a project on that system previously?
<perdmann>
yates: no... I just built one yesterday, and it worked with qemu
<perdmann>
But now i try to wrap that into an integration... And now it fails
<rburton>
'bb.process.NotFoundError: Execution of 'git rev-parse --abbrev-ref HEAD' failed: command not found'
<rburton>
you don't have git inside your container
<perdmann>
rburton: how can i add this? I built on a native machine...
<rburton>
well, what's different between this time and last? not git suggest you're doing a build inside a really minimal container? if so, add more stuff to the container.
<perdmann>
i dont use any container technique, iam running on the native machine. The same machine i have built a "Quick yocto built" yesterday
<rburton>
well it says you don't have git installed
<rburton>
so thats very much your problem to resolve
<perdmann>
git 2.33.0 is installed on that machine
<rburton>
delete tmp/ and try again
<rburton>
possibly, the hosttools links are all broken
<perdmann>
rburton: maybe the remote SSTATE CACHES break that built?
<perdmann>
rburton: i expected them to work...
<rburton>
yates: its just a theme, doesn't change much
<rburton>
perdmann: remote sstate work for me and no, this is before sstate happens
<perdmann>
rburton: its a slow machine ;-)
<perdmann>
rburton: i got the same error again ...
<rburton>
well, you'll have to figure out why it thinks git doesn't exist. it will be trying to run tmp/hosttools/git
<perdmann>
rburton: ok, its linking to the correct git... Thats not goot i guess?
<perdmann>
rburton: ok ... i initialize with "source sources/poky/oe-init-build-env sources/misc/build"
mrpelotazo has joined #yocto
<rburton>
and sources/misc/build/tmp/hosttools/git is a link to the right git binary?
<perdmann>
yes
<rburton>
weird
<perdmann>
i have put this source ... into another file and i source this one too... i will try without this
sakoman has joined #yocto
<perdmann>
rburton: no that was not the problem
davidinux has quit [Ping timeout: 245 seconds]
davidinux has joined #yocto
mrpelotazo has quit [Quit: Hasta la vista!]
mrpelotazo has joined #yocto
<perdmann>
rburton: its still not working. The links are ok. Is there something else i can check?
davidinux has quit [Ping timeout: 265 seconds]
mrpelotazo has quit [Quit: Hasta la vista!]
davidinux has joined #yocto
arlen_ has joined #yocto
<perdmann>
ERROR: Execution of event handler 'defaultbase_eventhandler' failed
arlen has quit [Ping timeout: 252 seconds]
oobitots has quit [Quit: Client closed]
ThomasD13 has quit [Ping timeout: 265 seconds]
mrpelotazo has joined #yocto
otavio_ has joined #yocto
otavio has quit [Read error: Connection reset by peer]
mrpelotazo has quit [Client Quit]
mrpelotazo has joined #yocto
mrpelotazo has quit [Remote host closed the connection]
mrpelotazo has joined #yocto
mrpelotazo has quit [Client Quit]
<sveinse>
Is there some way to remove (BACKFILL?) a specific package from an image - despite breaking deps?
<rburton>
what do you actually want to do
<rburton>
considering you're breaking depends, so most likely breaking something
<sveinse>
I have an image that is using a kernel that doesn't support lttng-modules and the dependency for lttng-modules is deep in the dependency hierarchy
mrpelotazo has joined #yocto
<rburton>
go and patch that depends to a recommends
<sveinse>
hmm, actually I can't find where this dep gets pulled in. Grepping for lttng-module doesn't reveal anything immediate obvious.
mrpelotazo has joined #yocto
mrpelotazo has quit [Changing host]
mrpelotazo has quit [Quit: Hasta la vista!]
mrpelotazo has joined #yocto
oobitots has joined #yocto
frieder has quit [Ping timeout: 265 seconds]
<qschulz>
sveinse: bitbake -g <image> and then read the .dot files with your favorite text editor
Net147 has quit [Ping timeout: 252 seconds]
goliath has quit [Quit: SIGSEGV]
<perdmann>
Is it possible that mnt/data/yocto/CTS_Yocto/sources/misc/build/../../../sources/poky/meta/classes/base.bbclass
<perdmann>
is a bad idea_
<sveinse>
thanks qschulz
<jaskij[m]>
sveinse: or get graphviz and draw an svg or something, if you prefer
<sveinse>
jaskij[m]: jep, I'm familiar with dot files
<jaskij[m]>
btw: who's using IRC? I'm not sure which parts of Matrix don't get forwarded to IRC. Say, did my emoji reaction work?
<qschulz>
if you have hours of CPU time to burn, please use graphviz ;)
<qschulz>
jaskij[m]: no it did not
<sveinse>
qschulz: I like to use my CPU on bitbake :P
<qschulz>
jaskij[m]: the Matrix bridge is very recent, so I'd say most of the folks here are still using IRC the old way :)
<jaskij[m]>
ah
<sveinse>
..and I'm fetish about it I think, as I just did a full Hardknott compile from no sstate on a wsl2 instance. Left my home office pretty warm :D
<jaskij[m]>
qschulz: I'm actually more worried I'll get an OOM while it's working, I've got like two gigs available right now
frieder has joined #yocto
<fabatera[m]>
Building a BOOST application on YOCTO Gatesgarth fails during do_configure. Tough, it builds on Zeus.
<fabatera[m]>
I've found adding DEPENDS = "autoconf-archive" works.
<fabatera[m]>
It can't recognize AX_BOOST_BASE from configure.ac
<fabatera[m]>
Am I missing something ? Should I add something to configure.ac so devtools add can recognize the dependency?
<qschulz>
If you're not compiling web browsers, it should be okay-ish
<qschulz>
IIRC we used to say 2GB*nproc in RAM is the minimum
<qschulz>
but anything involving web browsers... at least 32GB IIRC
<perdmann>
Is this helpfull for you? FileNotFoundError: [Errno 2] No such file or directory: '/mnt/data/yocto/CTS_Yocto/sources/misc/build/../../../sources/poky/meta-poky:/mnt/data/yocto/CTS_Yocto/sources/misc/build:/mnt/data/yocto/CTS_Yocto/sources/misc/build/../../'
<rburton>
fabatera[m]: adding DEPENDS was right, that application must be assuming that you have autoconf-archive installed and doesn't include copies of those macros
<jaskij[m]>
I've got 32 GiB on my workstation, of which 20 gigs is allocated to the VM which builds Yocto. Add in CLion, PyCharm and a browser open and I'll just say I'm living dangerously.
<sveinse>
I'm building boost, qt including webkit on my laptop with 32Gb. It succeeds, yet you're in for a long pause
<sveinse>
..on wsl2 and the sstate cache over ntfs which is SLOW!
<jaskij[m]>
I might ask to WFH, just because of the faster PC at home
<qschulz>
sveinse: might be a good idea to use the to-be-released or recently-released new NTFS kernel driver on Linux :)
<jaskij[m]>
5.15
<qschulz>
perdmann: the semi colon in it are dubious
Net147 has joined #yocto
Net147 has quit [Changing host]
Net147 has joined #yocto
<sveinse>
qschulz: yeah, the pain with ntfs and bb is not the sstate cache, but the git dl of linux kernels. THAT is slow. Like hours slow.
<jaskij[m]>
qschulz: the Paragon NTFS driver is in 5.15, which is on -rc3 now
<qschulz>
jaskij[m]: :+1:
<qschulz>
:thumb_up:
<sveinse>
like it
<qschulz>
👍
<qschulz>
aaah, found it :p
<perdmann>
qschulz: i only find colons in that string?
<qschulz>
perdmann: colon indeed. Long week-end :)
<sveinse>
wow, my utf-8 font has thumbs up codepoint :o
<qschulz>
perdmann: I can't even makes sense of what this path should really hold or in which variable it could be
<perdmann>
qschulz: of course. :) Clubs are open again ;-) Do you have an idea wgere tgus was added?
<qschulz>
there seems to be a mix of a layer directory, the build directory and... something else :p
<qschulz>
perdmann: Drove the motorcycle for 9h ~650km yesterday, not clubbing :)
<perdmann>
so the build directory should be placed somewhere else?
<perdmann>
qschulz: Oh, i see. youre located in Hildesheim?
<qschulz>
perdmann: clearly Bitbake expects a path and you're giving it three paths split by a colon
<qschulz>
perdmann: Vienna
<fabatera[m]>
<rburton> "fabatera: adding DEPENDS was..." <- Is there a better autotools way to set BOOST dependency on configure.ac so devtool add can get the dependency?
<sveinse>
Will the package-index index everything in tmp/deploy/ipk? Or just the packages relevant to that MACHINE that bitbake was called with?
<rburton>
fabatera[m]: afaik AX_BOOST_BASE is part of autoconf-archive, not boost
<perdmann>
qschulz: Oh, really wrong -.-
Tokamak has quit [Ping timeout: 252 seconds]
<perdmann>
qschulz: Where did i set this? :-D
<qschulz>
perdmann: bitbake -e <recipe that fails> and look for those paths
<jaskij[m]>
re: kernel, do you folks think 5.15 will be the next LTS?
<fabatera[m]>
rburton: yes, you are correct! My question was wrong ☹️.
<fabatera[m]>
I mean a way to set autoconf-archive dependency
<qschulz>
5.4, 5.10, probably 5.16?
<jaskij[m]>
earlier it was every fifth iirc
<jaskij[m]>
5.4 to 5.10 was the exception
<jaskij[m]>
but who knows?
<jaskij[m]>
so long it makes it into Yocto 3.5 ;)
<qschulz>
4.4, 4.9, 4.14, 4.19 indeed
<rburton>
fabatera[m]: DEPENDS += "autoconf-archive" is exactly what you want
<qschulz>
perdmann: with bitbake -e you have the history of the variable, so you can see where all gets messed up
<jaskij[m]>
qschulz: I'm still angry at my SoM vendor - outdated imx-sc-fw means I'm stuck at 4.14 :/
<fabatera[m]>
rburton: Thank you! I was wondering if the dependency could be auto generated. (It was not needed on previous Yocto zeus release).
<rburton>
no
<rburton>
build dependencies are explicit
<qschulz>
perdmann: have you also triple checked that you have the correct branch checked out for all your layers and Bitbake (if you use openembedded-core without poky)?
<qschulz>
otherwise, noidea.gif and I'm now afk so good luck :)
<qschulz>
jaskij[m]: sc-fw?
<qschulz>
jaskij[m]: imx SoCs support in upstream kernel is very good usually
<perdmann>
qschulz: wait what do i use? ...
<jaskij[m]>
qschulz: Might've misnamed. The firmware for the built-in M4 in i.MX8X. It must much the sec firmware, and one of the two is causing issues with the kernel if I try 5.4.
tnovotny has quit [Quit: Leaving]
<jaskij[m]>
afaik they wrote that firmware against pre-mainline kernel released by NXP
Tokamak has joined #yocto
<jaskij[m]>
qschulz: eh, getting that graph was not that bad - merely ten minutes on an R5 3600 for my biggest image (no graphics)
Net147 has quit [Ping timeout: 252 seconds]
dev1990 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
Net147 has joined #yocto
fbre has quit [Quit: fbre]
amitk has quit [Ping timeout: 260 seconds]
<sveinse>
jaskij[m]: I am too. We're stuck at rocko due to some vendor opengl driver. I'm sure there is newer kernel+yocto combos that work, but its quite the validation work. Dunfell/Gatesgarth/Hardknott has too new systemd for the kernel
<jaskij[m]>
oof
<jaskij[m]>
I at least was able to port the kernel and firmwares to Dunfell, might not be fully validated but seems to work nicely
<jaskij[m]>
sveinse: if you're using i.MX, afaik there's a reverse-engineered OpenGL driver for the VCG which has perf parity with the closed source one
<sveinse>
jaskij[m]: yes, the etnaviv - it's the same. However there are some GL operations etnaviv doesn't support. E.g. dithering is not great in etnaviv so the UX team put the veto foot down
<jaskij[m]>
and I really don't want an older systemd than what's in Dunfell, I really want the nice CAN support in systemd-networkd
<sveinse>
wait what, does systemd support operations from CAN?
<jaskij[m]>
it supports configuring socketcan interfaces
<jaskij[m]>
networkd specifically does
<sveinse>
haha, sorry, got a little overexcited here. Yeah, that makes sense. Good to know. We're using CAN
manuel1985 has quit [Quit: Leaving]
<sveinse>
I need to see if I can find an overview of the minimal kernel version of the respective systemd releases
<sveinse>
i got to go, but this has been very interesting. Thanks. See you around.
<jaskij[m]>
see you
<sveinse>
(we need a good forum/chat for this, but HW-ppl dislike IRC it seems)
<jaskij[m]>
sveinse: first of all, CM4 doesn't have built-in CAN, and using an external controller is always a mild PITA
<sveinse>
jaskij[m]: yep, I am aware. Major drawback
<jaskij[m]>
I'm not sure about Pi4, but the bcm283x in Pi1 to Pi3 is basically a settop SoC
<jaskij[m]>
there's i.MX9 around the corner too
<jaskij[m]>
they've already announced it, but haven't shown any SoCs yet
<jaskij[m]>
yeah, seems like Pi4 doesn't improve much in the peripheral department
<jaskij[m]>
yuck
<sveinse>
biggest advantage with the cm4 is the huge package/distro community. It's extremely well supported
<jaskij[m]>
guessing by you being here, you'll be running Yocto/OE anyway?
<jaskij[m]>
so that advantage doesn't exist then, does it?
<sveinse>
To be honest don't know. We had one product for 5 years on ubuntu (armhf) and decided that it wasn't worth the stretch to customize it the way we needed it to, enter Yocto. However Yocto is hard for many and it requires tremendous investment in build frameworks
<sveinse>
We're run yocto for 6 years or so
roussinm has joined #yocto
<sveinse>
The more I use Yocto, the more I enjoy it
<jaskij[m]>
yeah, Yocto will draw out every issue in build systems
<jaskij[m]>
that too
<jaskij[m]>
I've spent what, two weeks? trying to build SciPy
<jaskij[m]>
I don't like some of the stuff in meta-scipy, such as a lack of an optimized BLAS
<sveinse>
But it does have a curve, and engineers with yocto experience is very hard to get by. I've tried many times on delegating my tasks to others (as I am manager), internal and external looking
<jaskij[m]>
really?
<jaskij[m]>
I've got no plans to move rn, but last time I looked there was little job offers mentioning Yocto
<jonmason>
JPEW today, zeddii tomorrow. Lots of good heckling over the next few days at ELC
<zeddii>
;)
camus has quit [Ping timeout: 245 seconds]
camus has joined #yocto
florian has quit [Quit: Ex-Chat]
amitk has joined #yocto
goliath has joined #yocto
<perdmann>
qschulz: the problem was the way i made BBLAYERS relative...
<tlwoerner>
relatives can often be the source of issues…
<khem>
🙂
oobitots has quit [Quit: Client closed]
rfuentess has quit [Quit: donde está el mezcal? DONDE?!]
<vd>
does d.getVar('FOOBAR') return false if FOOBAR = ""?
nerdboy has joined #yocto
nerdboy has joined #yocto
nerdboy has quit [Changing host]
<jaskij[m]>
hmm.... I'm packaging something that's screwing up install paths somewhere... do I just fix it in `do_install_append` or patch CMakeLists.txt?
<kergoth>
vd: it returns the empty string if it's set to the empty string, or None if it hasn't been set to anything anywhere at all. both are considered false in an if block in python
<vd>
kergoth: thank you
<arr>
Good afternoon folks. I have a weird issue. A recipe foo-image depends on another recipe/package bar. If I run -c cleansstate for bar and then run bitbake on foo-image, bitbake understands that foo-image depends on bar package and rebuilds it (runs compile, install, package etc tasks including do_package_write_ipk) but it won't run rootfs and image tasks for foo-image. Any ideas why?
<arr>
foo-image has "IMAGE_INSTALL = bar" entry in .bb file
<khem>
jaskij: usually its better to fix the component build system in your case cmake and also submit upstream to make it cross compile friendly, second option would be to tweak it in do_install
<khem>
arr: did anything change in the package bar build after rebuilding ?
<khem>
perhaps it found the signatures to be exact and hence did not rebuild image
<arr>
khem, yes, there were changes
<khem>
ok did these changes result in output of build
<arr>
The package bar downloads a binary file as source and simply tars it up as compile step. The binary file changed for sure.
<arr>
But the versions and other metadata for the file didn't change.
<khem>
well it sounds like its sneaking in things under the nose of bitbake, if tarball changed I wonder why SRC_URI checksums did not change
<arr>
The .ipk file produced at the end of write_package_ipk has new file, so output of bar is correct
<khem>
I think you could change recipe for bar to explicitly download the tarball via SRC_URI and things will fall into place
davidinux has quit [Ping timeout: 245 seconds]
<arr>
khem, Ah. I will try that. Thanks.
<vd>
is there a mechanism similar to IMAGE_BOOT_FILES = "some_artifiact;different_name" but for the rootfs?
pgowda has quit [Quit: Connection closed for inactivity]
<khem>
vd: what usecase are you looking for ?
whuang0389 has joined #yocto
<vd>
khem: I'm embedded several images in my rootfs, for example an initrd, an overlay image, application container images, and the process could be generic: do_rootfs[depends] += "${MY_ROOTFS_DEPENDS}" and a bunch of files copied into ${IMAGE_ROOTFS} from a ROOTFS_POSTPROCESS_COMMAND function. If I could fill a variable with the "from;to" syntax, I
<vd>
could make a generic post process function.
<vd>
s/embedded/embedding
<khem>
hmmm, I guess this are all super image functions perhaps
<vd>
khem: so from the recipe or a configuration file I could do for example: MY_ROOTFS_EXTRADEPENDS += "core-image-minimal:do_image_complete" and MY_ROOTFS_EXTRAFILES += "core-image-minimal.squashfs;/var/lib/machines/app.img"
GillesM has joined #yocto
GillesM has quit [Client Quit]
GillesM has joined #yocto
<khem>
you could do this via a recipe for a new super image
wwilly has quit [Ping timeout: 240 seconds]
otavio_ has quit [Ping timeout: 252 seconds]
otavio has joined #yocto
<yates>
is there a overall log of a bitbake build stashed somewhere, perhaps in build/tmp? i'm not referring to the individual build/tmp/.../temp log.xyz logs
camus has quit [Ping timeout: 265 seconds]
camus has joined #yocto
<khem>
yates: look into build/tmp/log
<khem>
especially cooker folder contains the build logs
<yates>
aha! Beautiful, khem!
sakoman has quit [Quit: Leaving.]
<jaskij[m]>
khem: after looking around, seems like at least one path variable is used both for tests and as installation path, and it's altogether a complicated issue
<jaskij[m]>
so no upstream patches from me, unfortunately
<jaskij[m]>
Plus, it's entirely possible I'm passing wrong paths to the script
<Xagen>
when doing a build from toaster, can you force the checkout for a specific layer to be at a specific tag/commit-id instead of a branch?
wwilly has joined #yocto
davidinux has joined #yocto
amitk has quit [Ping timeout: 265 seconds]
kiran has quit [Ping timeout: 245 seconds]
kiran_ has joined #yocto
Tokamak has quit [Read error: Connection reset by peer]
jwillikers has quit [Remote host closed the connection]
arr has quit [Ping timeout: 252 seconds]
<RP>
JPEW: I suspect you're busy/distracted so this can with until later if so but depressingly I've discovered a problem with native sstate hashequiv :(
<JPEW>
RP: sad. We can talk at the meeting tomorrow
<RP>
JPEW: I thought that was cancelled?
<JPEW>
Oh was it?
<RP>
due to ELC
florian has quit [Ping timeout: 252 seconds]
<JPEW>
Ah
<JPEW>
Either way I'm free tomorrow morning (ELC doesn't start till 11 local time)