TheOneCurly has quit [Read error: Connection reset by peer]
TheOneCurly has joined #yocto
enok has joined #yocto
enok has quit [Ping timeout: 265 seconds]
prabhakalad has quit [Ping timeout: 252 seconds]
prabhakalad has joined #yocto
tammranil has quit [Remote host closed the connection]
tammranil has joined #yocto
Danct12 has quit [Quit: WeeChat 4.6.1]
Danct12 has joined #yocto
davidinux has joined #yocto
ablu has quit [Ping timeout: 245 seconds]
alessio has joined #yocto
rob_w has joined #yocto
ablu has joined #yocto
zeemate has joined #yocto
bigch1cken has joined #yocto
goliath has joined #yocto
Chaser has joined #yocto
eduter2 has joined #yocto
bigch1cken has quit [Quit: Client closed]
mckoan|away is now known as mckoan
<mcfrisk>
something in latest master is triggering dependency loop with old build configs. I can't see what or why https://pastebin.com/raw/USwDL7Yt
rfuentess has joined #yocto
<mcfrisk>
genericarm64 core-image-initramfs-boot exceeds INITRAMFS_MAXSIZE of 131072, new size 131545. Increase this for all or just genericarm64, rburton?
ptsneves has joined #yocto
zeddii has quit [Quit: ZNC 1.9.0+deb2build3 - https://znc.in]
<RP>
mcfrisk: we're seeing size problems on the autobuilder too :(
<mcfrisk>
RP: my modular kernel changes reduce the installed kernel modules a lot, no issues building that on genericarm64
<RP>
mcfrisk: right, but there are other challenges with patches in that series :(
Tyaku has joined #yocto
<mcfrisk>
RP: yea trying to get to addressing those
<RP>
mathieudb: I think the openssh upgrade may break the openssh based image tests
druppy has joined #yocto
<Tyaku>
Hello, I have created a Built-in Kernel Module to drive the LED's of our boards. This drive has a Kconfig, with a choice to select the backend (depending on the board it's not the same method to communicate with LED's). But I have a strange issue: In my linux-renesas_5.10.bbappend, I add the correct fragment depending on the machine and the correct fragment is added in kernel build dir, BUT in the kernel
<Tyaku>
configuration, it's like if the fragment is not taken. It use the defaults values from my custom Kconfig. Note: We have a lot of fragments that are working and in the renesas we don't need to put them in a variable to make them working, once they are in SRC_URI they are used.
<Tyaku>
I suspect a timing issue:
<Tyaku>
1. I have added a SRC_URI that download another repo in the linux-renesas receipe
<Tyaku>
2. I have SRC_URI:append:machine1 & machine2 that select the fragments
<Tyaku>
3. In the do_configure I copy the files from my "led driver" to the kernel sources
<Tyaku>
*do_configure:append
<Tyaku>
question : When is generated the configuration file of the kernel ? Which step ? do_compile ?
<mcfrisk>
Tyaku: don't modify sources in do_configure, do that via SRC_URI and do_fetch/do_patch
<Tyaku>
Thanks i'm going to try it!
Perflosopher038 has joined #yocto
Perflosopher03 has quit [Ping timeout: 272 seconds]
Perflosopher038 is now known as Perflosopher03
<Tyaku>
mcfrisk: I think it was the problem! I have the correct defines If I do the copy of my drivers files in do_patch:append ! Thanks
<rburton>
khem: yeah i expect the problem is "clang: remove llvm files" interacting badly
<JaMa>
thanks, I think there is a function to add it to a release without creating whole new layer entry (with everything except the "actual branch" copy pasted from other release)
<JaMa>
lovely :)
<rburton>
i'm just creating a new LayerBranch instance directly, its a bit tedious as the layer selectors are not sorted
<qschulz>
I'm wondering if it makes sense to have it set by default in the meson.bbclass?
<qschulz>
It's quite important in Buildroot due to shared sysroot, but in Yocto I'm not entirely sure it does make sense?
<JaMa>
rburton: are you able to also delete the mappings which don't make sense? e.g. "ERROR: Subdirectory for layer meta-luneos-backports-5.1 does not exist on branch master - if this is legitimate, the layer branch record should be deleted, ERROR: Failed to get last revision for layer meta-luneos-backports-5.1 on branch master" shown in https://layers.openembedded.org/layerindex/updates/42831/ is valid as
<JaMa>
backports-5.1 only makes sense for scarthgap and older, shouldn't be in styhead or master release
<JaMa>
I guess it exists in master release, because about a years ago the layer was introduced in master branch, but later removed once we upgrade to styhead
<rburton>
qschulz: <cough> i have a branch for that!
<qschulz>
rburton: uuuuuuuh, don't we want disabled rather?
<rburton>
i think you can argue the default either way, and enabled-by-default means we don't need to constantly look at what options are: the build breaks if the depends are not already present.
<qschulz>
could build if one of the PACKAGECONFIG that is enabled brings the dependency by default
<rburton>
if a mandatory dependency went to an optional one then disabled-by-default means new options silently are not enabled. enabled by default means new options are either enabled (if depends exist) or fail. i think i prefer the enabled-by-default behaviour.
<rburton>
JaMa: added qt6 for styhead and scarthgap. i don't have access to delete things.
<JaMa>
rburton: thanks
<qschulz>
rburton: I would assume that auto-features=disabled actually is less disruptive today?
<rburton>
qschulz: not at all - it turns off a load of things that are not explicitly turned on
<qschulz>
well... I guess it all depends how we want to break things, have packages with less things in it now (disabled), or have build fails because the dependencies aren't there
<JaMa>
rburton: and did you need to copy&paste everything from older release or did you just select the layer and release? I don't see how to populate the fields from existing release, so I might be doing something wrong or using wrong page
florian has joined #yocto
<rburton>
JaMa: in the django admin page i can create a new layer-branch instance directly
<JaMa>
true, but when I selected meta-qt6 and styhead, then it all stays empty below, did you just press save after that and it copied the info somehow?
<rburton>
i copied that over just in case it doesn't
<JaMa>
aha I though it's missing permission or wrong admin page, because for me it doesn't populate anything
<JaMa>
lets see how it works in 3 hours, thanks again
florian has quit [Ping timeout: 248 seconds]
<rburton>
qschulz: rebased if you want to poke further at that
<qschulz>
rburton: thanks, was just a thought, am not planning to work on it :)
<rburton>
drats, hoped i'd managed to donate a half-finished branch then
<qschulz>
rburton: good try though ;)
<rburton>
khem: so yeah clang is just broken now. clang deletes the llvm pieces from itself but doesn't actually depend on llvm in turn
<rburton>
no idea how that made it through meta-clang CI
lumag has joined #yocto
florian has joined #yocto
<JaMa>
rburton: I don't see any new failures with meta-clang in my world builds (other than mesa failures discussed on ML) luckily those meta-clang changes are now only on master branch while walnascar was branched before that
<rburton>
mostly variations on | x86_64-poky-linux-clang: error while loading shared libraries: libLLVM.so.20.1: cannot open shared object file: No such file or directory
<JaMa>
ah our builds don't change default TCMODE, that's why we might not see this
npcomp has joined #yocto
<JaMa>
or TOOLCHAIN = 'clang'
<rburton>
yeah that will do it
druppy has quit [Read error: Connection reset by peer]
eduter64 has quit [Quit: Client closed]
eduter64 has joined #yocto
<Jones42>
is there a way to get the versions of the DEPENDS used to build a package?
Chaser has quit [Ping timeout: 244 seconds]
<rburton>
not easily
<rburton>
but as you can't piecemeal build recipes, its less of a problem
<Jones42>
rburton: can you explain that last sentence? I'm not sure what you meant
grma has quit []
grma has joined #yocto
<rburton>
when people ask about versions of depends its because they want to set version limitations
<rburton>
if you just want to know for some other reason then eg things like pkgconfig will let you know the version of libraries you're linking against
<Jones42>
ah, ok. In our case it's just to have it for debug purposes. thanks!
<rburton>
every image has a manifest with the version of everything that was in it
<Jones42>
oh! yes, that rings a bell!
<Jones42>
thanks!
<rburton>
this is why you explain what you want to _actually_ do :)
rfuentess has quit [Remote host closed the connection]
Xagen has joined #yocto
Daanct12 is now known as Danct12
Articulus has quit [Quit: Leaving]
olani- has joined #yocto
mckoan is now known as mckoan|away
lumag has quit [Ping timeout: 272 seconds]
enok has quit [Ping timeout: 245 seconds]
florian has quit [Quit: Ex-Chat]
wmills_ has joined #yocto
goliath has quit [Quit: SIGSEGV]
enok has joined #yocto
savolla has quit [Quit: WeeChat 4.4.3]
paulg has quit [Read error: Connection reset by peer]
enok has quit [Ping timeout: 248 seconds]
<khem>
rburton: hmm, clang can not use the llvm stuff from core llvm recipe to removal perhaps should be other way around. The CI went through perhaps because it chooses clang to provide all llvm pieces
<khem>
the merge in core included merging libclc and spirv into llvm recipe which also trips it
<khem>
we have multiple ways its broken at the moment
leon-anavi has quit [Quit: Leaving]
<khem>
one thought was to straighten it along with merge but then I do not have a reference to compare to so perhaps it needs to be fixed as such before
<khem>
its the number of combinations we can have of these which makes it even worse
vermaete has joined #yocto
<khem>
llvm in core is building clang too but throwing it away and just reusing libclang for one tool
nerdboy has quit [Ping timeout: 260 seconds]
<khem>
meta-clang is building both and trying to use libllvm from llmv recipe, right now they are encroaching on each other severely
<khem>
now I wish we had merged meta-clang merge before this
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
florian has joined #yocto
merit has quit [Read error: Connection reset by peer]
merit has joined #yocto
vermaete has quit [Quit: Client closed]
enok has joined #yocto
merit has quit [Read error: Connection reset by peer]
<khem>
rburton: I can think of few ways forward, 1 install the llvm in core for mesa scope like rust does. I dont think there is anyone else consuming llvm from core other than mesa and revert the commit deleting the conflicts in meta-clang but that will have to be change again on merge of meta-clang to core, second option is to assume clang to provide LLVM needs when TOOLCHAIN = "clang" this might break
<khem>
yocto comaptible check but maybe we can live with that
merit has joined #yocto
<khem>
with merge this will not be an issue anymore
frieder has quit [Remote host closed the connection]
enok has quit [Read error: Connection reset by peer]
enok has joined #yocto
enok has quit [Client Quit]
enok has joined #yocto
zeemate has joined #yocto
ajcurtis84 has joined #yocto
eduter64 has joined #yocto
Jones42 has quit [Ping timeout: 276 seconds]
|Xagen has joined #yocto
Xagen has quit [Ping timeout: 252 seconds]
bigch1cken has joined #yocto
bigch1cken has quit [Quit: Client closed]
Bardon has joined #yocto
Bardon_ has quit [Ping timeout: 276 seconds]
enok has quit [Ping timeout: 252 seconds]
ajcurtis84 has quit [Quit: Client closed]
enok has joined #yocto
enok has quit [Client Quit]
enok has joined #yocto
cyxae has quit [Quit: cyxae]
eduter64 has quit [Quit: Client closed]
enok has quit [Ping timeout: 252 seconds]
druppy has joined #yocto
Chaser has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
druppy has quit [Client Quit]
druppy has joined #yocto
kanavin has quit [Ping timeout: 265 seconds]
druppy has quit [Read error: Connection reset by peer]
druppy has joined #yocto
ptsneves has quit [Ping timeout: 268 seconds]
druppy has quit [Quit: druppy]
druppy1 has joined #yocto
dgriego has quit [Quit: Bye]
druppy1 is now known as druppy
druppy has quit [Client Quit]
druppy has joined #yocto
druppy has quit [Remote host closed the connection]
druppy has joined #yocto
|Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
druppy1 has joined #yocto
druppy has quit [Ping timeout: 245 seconds]
druppy1 is now known as druppy
derRicha1d is now known as derRichard
druppy has quit [Quit: druppy]
druppy has joined #yocto
druppy has quit [Read error: Connection reset by peer]
sakoman has quit [Ping timeout: 244 seconds]
sakoman has joined #yocto
reatmon_ has quit [Remote host closed the connection]
reatmon_ has joined #yocto
Kubu_work has quit [Quit: Leaving.]
dgriego has joined #yocto
<dvergatal>
hi all
<dvergatal>
i have a question if i'm using PACKAGE_BEFORE_PN the subpackage is being added as RDEPENDS and i would not like it to be as RDEPENDS is it possible?