jwillikers has quit [Remote host closed the connection]
hmw[m] has joined #yocto
shoragan|m has joined #yocto
rostam98[m] has joined #yocto
Spectrejan[m] has joined #yocto
berton[m] has joined #yocto
Emantor[m] has joined #yocto
moto_timo[m] has joined #yocto
jonesv[m] has joined #yocto
meck[m] has joined #yocto
ejoerns[m] has joined #yocto
PascalBach[m] has joined #yocto
barath has joined #yocto
tokamak[m] has joined #yocto
jwillikers[m] has joined #yocto
t_unix[m] has joined #yocto
Pierre-jeanTexie has joined #yocto
hpsy has joined #yocto
m1kr0[m] has joined #yocto
jordemort has joined #yocto
camus has quit [Ping timeout: 268 seconds]
camus has joined #yocto
Alban[m] has joined #yocto
dwagenk has joined #yocto
khem has joined #yocto
behanw[m] has joined #yocto
nicolas[m]12 has joined #yocto
amitk has joined #yocto
lexano[m] has joined #yocto
tp43_ has quit [Ping timeout: 272 seconds]
ndec[m] has joined #yocto
michaelo[m] has joined #yocto
halstead[m] has joined #yocto
Saur[m] has joined #yocto
falk0n[m] has joined #yocto
michaelo[m]1 has joined #yocto
peterp has joined #yocto
<peterp>
Hi, I'm trying to compile a custom bootloader provided by our vendor and it requires that it has a dtsi file available from the kernel recipe. How do I go about sharing this file while I'm building the bootloader? I added a DEPENDS on the kernel, but now I'm stuck and can't seem to find the answer in the docs and googling...
camus1 has joined #yocto
camus has quit [Ping timeout: 268 seconds]
camus1 is now known as camus
zeddii has joined #yocto
wing0 has quit [Quit: WeeChat 3.1]
roussinm has quit [Quit: WeeChat 3.3-dev]
paulg has quit [Ping timeout: 248 seconds]
rob_w has joined #yocto
vmeson has quit [Ping timeout: 268 seconds]
kranzo has joined #yocto
sbach has quit [Read error: Connection reset by peer]
sbach has joined #yocto
dtometzki has joined #yocto
goliath has joined #yocto
bps has quit [Read error: Connection reset by peer]
bps has joined #yocto
bps has joined #yocto
LetoThe2nd has joined #yocto
<LetoThe2nd>
yo dudX
dmoseley has quit [Read error: Connection reset by peer]
dmoseley has joined #yocto
<cocoJoe>
good morning
<qschulz>
peterp: One way would be to deploy the dtsi of the kernel and take the dtsi from the deploydir in u-boot and add it in the configure task or similar, and add a dependency on virtual/kernel:do_deploy for said task from u-boot
<qschulz>
but i'm not entirely sure it makes sense, device trees used in U-Boot and the kernel are often different. Similar but different
<qschulz>
the drivers don't always expect the same properties for example
<qschulz>
so the other way could be to just duplicate the dtsi from the kernel and add it to the u-boot recipe directly
leon-anavi has joined #yocto
d0ku has joined #yocto
leon-anavi has quit [Quit: Leaving]
kranzo has quit [Ping timeout: 246 seconds]
peterp has quit [Quit: Client closed]
cocoJoe has quit [Ping timeout: 246 seconds]
argonautx has joined #yocto
wCPO has joined #yocto
<wCPO>
Is initramfs-live-boot meant to be used without the "initramfs-framework"? AFAIU the initramfs-framework /init mounts the rootfs and switch_root to it. We are using the live/iso FSTYPE so the rootfs is read-only and initramfs-live-boot can't do its thing as the rootfs is read-only
mihai has quit [Remote host closed the connection]
<RP>
moto-timo: looks like a good fix, thanks
<qschulz>
moto-timo: now I need to keep up with the ML to fix those in the various documentations too :) cc michaelo
<qschulz>
might have missed a few since I was not subscribed to the oe-core ML
<RP>
rburton: we have a buildtools issue now? :/
florian has joined #yocto
goliath has quit [Quit: SIGSEGV]
<rburton>
RP: the glibc one i moaned about, or another one?
rob_w has quit [Quit: Leaving]
florian has quit [Ping timeout: 248 seconds]
jwillikers has joined #yocto
goliath has joined #yocto
camus1 has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
<RP>
rburton: glibc one
<rburton>
chasing it down as we speak
<rburton>
its annoyingly slow to bisect :)
<wCPO>
Is read-only-rootfs unsupported when systemd is used exclusively? The script seems to be part of initscripts which is used only by sysvinit, right?
<LetoThe2nd>
wCPO: nope, it certainly works.
<wCPO>
LetoThe2nd: I will continue debugging then. We are building a iso (which means the rootfs is read-only) and the rootfs is mounted early as / read-only, so initramfs-live-boot isn't working as it can't create new directories for the overlayfs it seems
tp43_ has joined #yocto
<LetoThe2nd>
wCPO: i have no experience with ISOs, sorry.
goliath has quit [Quit: SIGSEGV]
camus has quit [Quit: camus]
<JPEW>
Are circualar RDEPENDS allowed? I added a task with do_foobar[rdeptask] = "do_foobar" and it fails on some recipes with a circular dep error
<RP>
JPEW: no, they're not
<JPEW>
Ok, so what I did with do_foobar is allowed and I should fix the recipes?
<JPEW>
Kinda makes me want to add a dummy task that does the rdeptask as a check to make sure no one adds more since there doesn't currently appear to be a check
<RP>
JPEW: hmm, I think that is allowed
<RP>
JPEW: I think the code knows to remove self references
<RP>
JPEW: it is possible since there is meta/recipes-devtools/xmlto/xmlto_0.0.28.bb:do_populate_sysroot[rdeptask] = "do_populate_sysroot"
argonautx has quit [Quit: Leaving]
<RP>
JPEW: I suspect if you add in general dependencies there are problems :/
<RP>
JPEW: usually you're looking for recrdeptask and not rdeptask
ptsneves has joined #yocto
<ptsneves>
Hey all. Does anybody know why $(( )) expressions which are POSIX compliant fail in dunfell? Am I missing something?
<ptsneves>
when i mean fail, i mean the parsing fails
<qschulz>
ptsneves: are you appending/prepending to an already existing task?
<ptsneves>
yes
<ptsneves>
i am intrigued with that question. Do you think it makes a difference?
<qschulz>
are you sure you're appending to a shell task?
<qschulz>
we have support for python tasks
<qschulz>
and some are
<JPEW>
RP: I'm trying to capture the RDEPENDS graph for SBoM SPDX generation. What I would like to do is encode the runtime dependencies in the SPDX document, but for that to work, all the SPDX documents for the runtime dependencies need to be fully generated first. It seems like rdeptask is the correct thing to use there?
<ptsneves>
qschulz yes i am. I am putting the $(( in a task which has other shell stuff. The same happens for $(( inside functions executed by bb.build.exec_func
<ptsneves>
funny thing is that there are plenty of expr calls in yocto layers and no $((. At first i thought that $(( was a bashism but it is not.
<ptsneves>
regardless i would not expect the $(( to make the parser fail
<qschulz>
ptsneves: bitbake probably is looking for strings starting with $ and tries to replace it if it has a variable matrching the name
<JPEW>
ptsneves: I *think* bitbake has it's own shell parser that probably doesn't understand $(())
tp43_ has quit [Ping timeout: 245 seconds]
<qschulz>
there's variable substitution done during parsing I'm absolutely sure of it
sakoman has joined #yocto
<RP>
JPEW: Do you mean the package runtime dependencies or the RDEPENDS of the recipe?
<RP>
JPEW: RDEPENDS are usually incomplete until after do_package and the fact some things are only in DEPENDS
<JPEW>
RP: The latter, which I can get. The hard part is I don't want to parse *every* pkgdata file to figure out the mappings, so I was trying to use rdeptask/RDEPENDS/BB_TASKDATA to only parse the ones the recipe actually cares about (this is perhaps the wrong track)
<RP>
JPEW: I think you're nearly on the right track :)
<JPEW>
RP: Also, you need the runtime dependencies to have run their SPDX generation before the current recipe, which I *think* means rdeptask?
<ptsneves>
JPEW qschulz i know that the parser does a bit more than just substitution but it should not fail in places where no substitution happens. I can reproduce the failure with echo $((1 +2 ))
<RP>
JPEW: the do_package_write_* code already has to do this for different reasons so you want to emulate something like that I'd guess
<RP>
JPEW: do_package_write_ipk[rdeptask] = "${DEBIANRDEP}" - I'd have a look at that code, see if the PACKAGES = "" anon python helps
<JPEW>
RP: Thanks
vd has quit [Quit: Client closed]
<RP>
JPEW: in general I'd think you could get away with going after packagedata. The hard part is that you'd therefore want the SPDX doc gen after packagedata for some reasons and before packagedata for others :(
<JPEW>
RP: Ya, that was the conclusion I was coming to
<JPEW>
Rp: Hence my do_create_spdx[rdeptask] = "do_create_spdx", which doesn't work
<fray>
JPEW I'm just catching up, but I worked on planning something that sounds similar..
<fray>
We had broken the problem into three phases.. First phase, source code download -- along w/ SPDX to Source code mappings.. (either downloaded or generated)
<fray>
We'd the patch the sources and configure them.. and repeat the process.. any files that changed would have to be scanned or loaded.. and new files generated tagged as generated configurations
<fray>
and then a pass AFTER the compilation, where the binaries were interogated to see what the _dwarf_ debug said they all came from, then attached to the source mapping of this (and other) dependencies..
<fray>
that way we could find and capture staticly linked, as well as functions embedded in headers.
<JPEW>
fray: Ya, you can break it up for thes source scanning, which I'm not dealing with. I'm just worried about creating the SPDX documents. At the end of the day, you need each SPDX document to be created in (runtime) depenency order because each document encodes the SHA1 of the thing it references, which means it must be a DAG
<fray>
the end result was a set of XML files that together game a full picture of original source -> patches/configured source -> binary
vd has joined #yocto
<fray>
(the reason the planned patches/configured was there, most time patches were not somethign that people had scanned.. so it would highlight places that may need manual attention.. adn the configured/generated is stuff that got referenced by the binary..)
<RP>
JPEW: I think we'd need to understand exactly what kind of circular reference that is causing :/
<RP>
JPEW: this stuff can get tricky. I suspect I'm not in the best of states to think clearly about it either :(
<fray>
I never implemented what I designed, but we didn't see any circular references in it, but it did expand the sysroot information required
<JPEW>
RP: Yep. I can compile a list of the ones I find quick
vmeson has joined #yocto
<JPEW>
RP: Hmm, ok. So there are a few circular deps that might be considered bugs (weston <=> weston-conf for example.... oops), but a lot are the ptest packages... going to have to have a thing about it
<JPEW>
s/thing/think/
paulg has joined #yocto
<fray>
I think I didn't run into that stuff when I did my planning, cause we didn't care out package dependencies. We cared about sources, and embedded binary source dependencies. The image would just say anything installed on it, got linked back to the SPDX files.. (including configuration files, etc.)
<fray>
so packages were limited to 'I provide the follow.... When I was compiled, I needed the following..." the image was the only thing that would have done "I use the following..."
<JPEW>
fray: Ya, I'm leveraging the recipe metadata a lot more
<RP>
JPEW: I think the runtime deps can end up circular, just because the inter-package deps are much more granular than the recipe level :/
<JPEW>
RP: Right
<wCPO>
How would I disable the pcbios machine feature for the genericx86-64 machine? I tried MACHINE_FEATURES_remove = "pcbios" in local.conf but syslinux is still added to the iso
<fray>
not sure I mentioned, but our expectation was also to create a ${PN}-spdx package (like the -lic package)
<JPEW>
fray: package.bbclass already had the list, I just made it dump it out somewhere
tre has joined #yocto
<fray>
Is that list complete? I thought it only referred to items from within the existing sources
<JPEW>
fray: Seems complete to me
<fray>
Does it include all of the headers from external items, like glibc?
<JPEW>
fray: tes
<JPEW>
yes
d0ku has quit [Quit: Client closed]
<fray>
ok, I thought that stuff had been filtered.. Also the other check is, compile something against a static .a (with debug symbols) do the references hold?
<fray>
those were teh three cases we identified. 'normal' shared build. build w/ functions (and other bits) embedded in headers.. and 'hidden' static libraries from external providers being linked in.. (assumed to include debug)
<JPEW>
Not sure about the .a. I think it will as long as the .a has debug info
<fray>
the issue w/ the .a when I was planning this was.. pkgA provides a static.a (with debug symbols).. pkgB requires pkgA, but doesn't require pkgA's build dependencies.
<fray>
so when linked and debugs processed, the referenced files wouldn't be directly avaialble. We could reference them, but wouldn't know the checksums, unless we processed the pkgA spdx file and read them ourselves
<fray>
(I'm assuming the .a was processed in pkgA, and an SPDX was generated that referenced the orgiinal upstream sources)
<JPEW>
fray: The eaiser path would be to add a STATIC_LINK relationship
<JPEW>
fray: Well, "easier" from a SPDX standpoint. Knowing a static link has occured is hard :)
<fray>
knowing it was a static link is hard, but knowing we have references to things we can't find (when prcessing debug) should make it more obvious it's a depdnency coming from a dependency..
<fray>
there is no way (that I know of) that a dependency could come in that isn't a dependency of a parent. So at worst case, you could always say "I depend on XYZ, but can't find it" triggering a second program to scan the SPDX of my 1st order dependencies and finding/filling in the pieces..
<fray>
but the key, we can't directly scan the dependency (rm_work and all), but we can read our dependencies SPDX and transfer data
<JPEW>
Ya, we can mark the files with a GENERATED_FROM NOASSERTION
<JPEW>
Meaning, we know it was generated from somewhere, but we have no idea what that is :)
<fray>
but I like your solution of using the debugsrc output. I had overlooked that and was creatign a dwarf scanner..
<fray>
(when I ran out of time)
<fray>
ya, should still list the files you don't know about, then another tool can post-process to find hte matches..
<fray>
(listing the build time dependencies can help with that match)
<JPEW>
Ya, I have all those; I split each generated package into it's own SPDX document, and then there is also a document for the recipe itself, so you can trace back the package -> recipe -> build dependencies (DEPENDS)
<JPEW>
fray: Ok, I have to doing a GENERATED_FROM NOASSERTION any any unknown debug sources now
<alimon>
In bitbake which is the step/flow to load a dynamic-layers files, I have a bug in OE/bitbake master for android-tools recipe that has the same version but one of them is in a dynamic-layer in meta-clang/dynamic-layers/selinux and the other one in meta-oe, so I select to use the meta-oe via preferred_version and ends in
<alimon>
ERROR: Multiple versions of android-tools-conf-configfs are due to be built (/home/builds/oe-rpb-master/build-410c-2/conf/../../layers/meta-openembedded/meta-oe/recipes-devtools/android-tools/android-tools-conf-configfs_1.0.bb
<alimon>
/home/builds/oe-rpb-master/build-410c-2/conf/../../layers/meta-clang/dynamic-layers/selinux/android-tools/android-tools-conf-configfs_1.0.bb). Only one version of a given PN should be built in any given build. You likely need to set PREFERRED_VERSION_android-tools-conf-configfs to select the correct version or don't depend on multiple versions.
<alimon>
also I noticed that dynamic-layers are not load frist I changed the version to 10 where is provided by meta-clang and got a warning about not begin available
goliath has joined #yocto
camus has joined #yocto
<alimon>
RP: rburton any idea ^
<alimon>
khem: just figure out you are the maintainer of meta-clang, any reason to have android-tools in the dynamic-layers in meta-clang instead of meta-oe?, this unhidden the bug above, that is good
LetoThe2nd has quit [Quit: Connection closed for inactivity]
cocoJoe has quit [Quit: Quit]
<RP>
alimon: that usually means the recipes aren't identical and one provides something the other doesn;t
<RP>
alimon: also, layer priorities may override PREFERRED_VERSION :/
<alimon>
RP: yep, it differs with new and old syntax for appends
<alimon>
RP: i will try to see if works, but still is a bug for me, for example if i select a preffered version of android-tools to 10 that is in meta-clang/dynamic-layers at frist bitbake parse displays warning about not being available
<alimon>
then there is other issue about not being able to select the preferred version because two recipes are in the file_set inside bitbake
camus has quit [Ping timeout: 272 seconds]
<RP>
alimon: the trouble is I doubt you can change behaviour like that without breaking other things, at least if I understand the issue correctly
<RP>
alimon: if the provides are different, it will break regardless of how much you set that stuff
<alimon>
RP: yeah, i think the best solution is move the android-tools new recipe inside meta-oe
leon-anavi has joined #yocto
bps has quit [Ping timeout: 248 seconds]
ptsneves has quit [Quit: Connection closed]
leon-anavi has quit [Quit: Leaving]
<fray>
ya
<fray>
'er.. wrong channel
tp43_ has joined #yocto
LetoThe2nd has joined #yocto
dev1990 has joined #yocto
<LetoThe2nd>
khem: howdy! Can you recommend a riscv board that (mostly) world ootb with meta-riscv?
fitzsim has quit [Ping timeout: 252 seconds]
jwillikers has quit [Remote host closed the connection]
<manuel_>
smurray: Ah, I see. Got it now. Thanks :)
mrdmitry has quit [Quit: WeeChat 2.8]
<manuel_>
What exactly means distro-less?
<abelloni>
with DISTRO not defined
<manuel_>
yeah but what does that give me? Or rather, what does it not give me? Why do I define a distro in the first place? Seems to work without just as well
<marex>
abelloni: DISTRO="nodistro" , no ?
<fray>
"nodistro" is just a set of defaults..
<marex>
manuel_: the stuff defined in yourdistro.conf is not defined ... is what it gets you
<JPEW>
manuel_: it can be useful if you want a lot of different things to behave with a similar (centralized) policy
<JPEW>
e.g. different machines
<marex>
JPEW: that ... is not entirely clear ?
<marex>
JPEW: I mean, that does not really explain what nodistro is about
<marex>
JPEW: if you want centralized policy, dont you define your own distro in distro layer ?
<JPEW>
marex: Ya, nodistro means "I'm not going to do that" (I think, I don't use nodistro TBH)
* tlwoerner
uses nothing but nodistro
* marex
uses many custom distros
<tlwoerner>
what's all this PUH-KEY stuffy about?
<manuel_>
Gonna look into this nodistro thing another time.
<marex>
tlwoerner: there is actually one other thing which I was pondering about /wrt poky -- whether it is a good idea to include poky.conf in customdistro.conf to get the "sane defaults" like some distros do, or whether it is better to copy the whole poky.conf over and filter out what is useless
<marex>
I cant decide which way is better to go about it
<manuel_>
NON_MULTILIB_RECIPES:append = " crash" <---- the colon here looks strange
<manuel_>
marex: I think this whole poky thing is more confusing than in helps. At least to me, as a beginner.
<marex>
manuel_: it is a reference distro for starters ...
<marex>
better than having nodistro as a starting point , heh
<tlwoerner>
poky is the sample distro that's used for testing
<abelloni>
marex: if you include poky.conf and suddenly this switches from X11 to wayland or sysv to systemd, you can have some surprises
<tlwoerner>
s/if/when
<marex>
abelloni: well ... yes ... that's solved if you duplicate large part of poky.conf into your own customdistro.conf
<marex>
abelloni: on the other hand, some of the defaults defined in poky.conf might be updated (like equivhash) and that would be beneficial to your customdistro.conf
<tp43_>
I am getting access denied or repo not exported for various branches of /meta-respberrypi
<marex>
tp43_: where ?
<marex>
locally ? permissions issue ?
<tp43_>
Nevermind, my fault. I had a type. the i at the end with missing.
<tp43_>
marex thx for reply
florian has joined #yocto
sakoman has quit [Read error: Connection reset by peer]
sakoman has joined #yocto
dvorkindmitry has joined #yocto
<dvorkindmitry>
how can I enable myscript@eth1.service in .bb file?
<tp43_>
I added the meta-raspberrypi to my bblayer.conf and set MACHINE to raspberrypi4-64.conf. But now how do I bitbake ___? bitbake core-image-minimal didn't work
<tp43_>
when I run bitbake-layers I get error "no response from server"
LetoThe2nd has quit [Quit: Connection closed for inactivity]
<tp43_>
Aha, got it. $bitbake rpi-basic-image, or rpi-hwup-image or rpi-test-image
florian has quit [Ping timeout: 268 seconds]
jwillikers has quit [Quit: jwillikers]
jwillikers has joined #yocto
<tp43_>
no that might not be right
<tp43_>
My bitbake isn't working after adding raspberrypi, so I reverted, deleted the pi line in bblayers.conf and changed back the machine in local.conf. And it wont build the simple core-image-minimal emulated one either now. I deleted the bitbake.lock too, that didn't help.
aleblanc_ has joined #yocto
<tp43_>
Your version of local.conf was generated from an older/newer version
aleblanc_ has quit [Remote host closed the connection]
aleblanc_ has joined #yocto
<tp43_>
ok, I copy that file over it mentioned in meta-poky/conf/local.conf.sample to build/conf/local.conf and it is building again ok.