lexano_ has quit [Remote host closed the connection]
xmn has quit [Quit: ZZZzzz…]
xmn has joined #yocto
Nostromo8 has quit [Ping timeout: 245 seconds]
GNUmoon2 has quit [Ping timeout: 240 seconds]
davidinux has quit [Ping timeout: 240 seconds]
GNUmoon2 has joined #yocto
alimon has quit [Ping timeout: 240 seconds]
Minvera has joined #yocto
alimon has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
goliath has quit [Quit: SIGSEGV]
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #yocto
<khem>
RP: some distros e.g. archlinux have already upgraded to gcc13 and our existing uninative tarballs dont work with it all binaries using ld.so from uninative are segfaulting
* khem
disables uninative
jclsn has quit [Ping timeout: 246 seconds]
jclsn has joined #yocto
sakoman has quit [Quit: Leaving.]
sakoman has joined #yocto
seninha has quit [Quit: Leaving]
mason has quit [Quit: leaving]
mason has joined #yocto
juserr[m] has joined #yocto
juserr[m] has left #yocto [#yocto]
ecdhe has quit [Read error: Connection reset by peer]
ecdhe has joined #yocto
Minvera has quit [Ping timeout: 268 seconds]
thomasd13 has joined #yocto
sakoman has quit [Quit: Leaving.]
xmn has quit [Quit: ZZZzzz…]
amitk_ has joined #yocto
xmn has joined #yocto
<JaMa>
khem: I've built my own uninative with your gcc-13 upgrade and I'm using that (on gentoo with gcc-13 on host)
rfs613 has quit [Remote host closed the connection]
rfs613 has joined #yocto
zpfvo has joined #yocto
bps has joined #yocto
bps has quit [Changing host]
bps has joined #yocto
rich1234 has joined #yocto
Thorn has joined #yocto
vladest has joined #yocto
florian has quit [Ping timeout: 268 seconds]
GNUmoon2 has quit [*.net *.split]
zelgomer has quit [*.net *.split]
GNUmoon2 has joined #yocto
zelgomer has joined #yocto
rich1234 has quit [Quit: Client closed]
rfs613 has quit [Quit: restart]
rfs613 has joined #yocto
bps has quit [Ping timeout: 276 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
xmn has quit [Ping timeout: 240 seconds]
<rburton>
RP: was that the xorg ppc thing?
tnovotny has joined #yocto
<LetoThe2nd>
yo dudX
d-s-e has joined #yocto
bps has joined #yocto
bps has joined #yocto
<TRO[m]>
I have trouble activating systemd for poky (and disable sysvinit) other than local.conf or in a new distro. I can not set it in a classes class and INHERIT it in local.conf.
<TRO[m]>
Is this supposed to work like this? Also I need to set INIT_MANAGER = "systemd" to configure it (that's not in the docs?)
<mckoan>
TRO[m]: section "Enable systemd in the final image"
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
<rburton>
TRO[m]: if you're using poky then INIT_MANAGER:forcevariable = "systemd" in local.conf will force it to use systemd. if this is for production, don't use poky: make your own distro.
<TRO[m]>
mckoan: thank you - yes, in local.conf - since local.conf is only for LOCAL changes and should not checked in there should be a better way?
<TRO[m]>
rburton: yes, own class... will try the force thing
<rburton>
the proper way is to create your own distro
<rburton>
and that can pick systemd
<TRO[m]>
yes, sorry mean distro...
<rburton>
if you have your own distro then just INIT_MANAGER="systemd" in it will do the right thing.
<TRO[m]>
but still the INIT_MANAGER is not in the docs
<rburton>
so it isn't. it's in the 3.0 release notes, but not the reference
<TRO[m]>
and not in koan wiki ;)
<rburton>
michaelo: fyi INIT_MANAGER is missing from the variable reference. Do you have a private todo list or should a bug be filed?
florian has joined #yocto
<TRO[m]>
I mean the whole problem is that there is no way (other than local.conf and own distro) to set INIT_MANAGER before the poky.conf is parsed and require INIT_MANAGER (it will use POKY_INIT_MANAGER sysvinit then) - at least I do not know a way. IMHO if you inherit some global class it should be parsed first before parsing the distro.
<rburton>
TRO[m]: sure there is
<rburton>
TRO[m]: if you're using poky then set POKY_INIT_MANAGER instead. or use INIT_MANAGER:forcevariable. Or write your own distro.
<TRO[m]>
I do not see any difference when using INIT_MANAGER:forcevariable or INIT_MANAGER when using bitbake-getvar -r core-image-minimal INIT_MANAGER
<TRO[m]>
in both cases poky.conf will parsed first and require POKY_INIT_MANAGER
<TRO[m]>
only change is to set it in local.conf, yes or own distro
<rburton>
oh sorry missed the bit about a global class
<rburton>
its a distro setting, should be in the distro
<d-s-e>
I try to build an application that creates code from protobuf files that is included during the build. The files are created in build/tmp/work/... which seems to be correct, but the compiler looks in build/workspace/sources/...
tnovotny has quit [Ping timeout: 246 seconds]
<d-s-e>
What is the usual way to fix this?
<d-s-e>
Maybe developing in build/tmp/work/... could do it, but that seems not right.
perceval[m] has joined #yocto
<rburton>
d-s-e: sounds like an out-of-tree problem. build files go into the build directory, so the makefile needs to know to look there and not the source tree.
<rburton>
i'm guessing the app is using autotools?
<d-s-e>
hmm, CMAKE_SOURCE_DIR is set to the workspace. I thought, that the sources are copied to tmp/work before the build and everything is done there. But maybe I did get that wrong.
<d-s-e>
cmake
<rburton>
ah cmake. not sure how to fix that but the bug is almost certainly in the cmakelists, looking in source not build tree.
<perceval[m]>
Hello all,
<perceval[m]>
I'm strugling with linux-intel recipe that does not take my config fragment that I've put in my own layer under recipes-kernel/linux/files and added to linux-intel_5.4%.bbappend file in SRC_URI and I set FILESEXTRAPATHS.
<perceval[m]>
I saw that linux-intel require recipes-kernel/linux/linux-yocto.inc so fragments should be handled correctly :s
<perceval[m]>
do you have an idea on what is going on?
<perceval[m]>
and how to fix that :)
<mckoan>
perceval[m]: are you sure you are using linux-intel_5.4? and how's your recipe?
<rburton>
also how do you know its not being used? if your turning on a kernel module then you'll also need to install the module.
<d-s-e>
rburton: seems so. I think it depends on the variables CMAKE_SOURCE_DIR/CMAKE_CURRENT_SOURCE_DIR/CMAKE_CURRENT_BINARY_DIR in the cmakelists, the latter is set correct, the others not. But I don't know, where the values come from ...
davidinux has quit [Quit: WeeChat 3.5]
<perceval[m]>
mckoan: yes I'm sure I set the prefered kernel in my distro configuration
<perceval[m]>
rburton: what do you mean, kernel modules are not handled automatically by the build if it is in the config?
tnovotny has joined #yocto
bps has quit [Ping timeout: 246 seconds]
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #yocto
bps has joined #yocto
prabhakarlad has quit [Quit: Client closed]
<mckoan>
perceval[m]: and do you have .ko files in /lib/modules ?
<rburton>
perceval[m]: i mean just because a kernel build a module doesn't meant it gets installed in the rootfs
<perceval[m]>
Yes I have .ko files in /lib/modules
<perceval[m]>
my problem is that when I check the config file in my work directory linux-intel/5.4.193.../image/boot/config-5.4.193-intel-pk-standard, the configs fragments are not applied
seninha has joined #yocto
goliath has joined #yocto
d-s-e has quit [Ping timeout: 246 seconds]
demirok has joined #yocto
Vonter has quit [Ping timeout: 240 seconds]
prabhakarlad has joined #yocto
Vonter has joined #yocto
tnovotny has quit [Ping timeout: 240 seconds]
zwelch has quit [Read error: Connection reset by peer]
tnovotny has joined #yocto
<mckoan>
perceval[m]: what is the output of : bitbake -c kernel_configcheck -f virtual/kernel
<perceval[m]>
nothing
<perceval[m]>
NOTE: Tasks Summary: Attempted 447 tasks of which 444 didn't need to be rerun and all succeeded.
<perceval[m]>
Summary: There were 4 WARNING messages shown.
<perceval[m]>
the warning are due to my edition to debug what is going on
<perceval[m]>
Yes I've done exactly what the first articel says
<perceval[m]>
* Yes I've done exactly what the first article says without any success
<perceval[m]>
thanks for the debugging tip ;)
<Flora[m]>
‼️Polymath Cryptocurrency is the most profitable Asset in financial stock market 💯 profit…make up to $200k and more. Kindly pop a private message on TG using the below Hyper link.
rob_w has quit [Read error: Connection reset by peer]
ecdhe has joined #yocto
Vonter has quit [Ping timeout: 240 seconds]
<ecdhe>
I'd like to switch to `kas' from a homebrew makefile solution. My makefile would clone layer repos and checkout the correct branches/commits (which `kas' handles nicely) but my makefile would also download a gzipped archive of my build/downloads/ directory and unpack it. Is there a way to get 'kas' to run this step?
<ecdhe>
Since 'kas' downloads layers, I wondered if I could provide a pre-populated downloads directory through a layer.
Vonter has joined #yocto
esben[m] has quit [Quit: Bridge terminating on SIGTERM]
shoragan[m] has quit [Quit: Bridge terminating on SIGTERM]
ericson2314 has quit [Quit: Bridge terminating on SIGTERM]
Salamandar has quit [Quit: Bridge terminating on SIGTERM]
barath has quit [Quit: Bridge terminating on SIGTERM]
khem has quit [Quit: Bridge terminating on SIGTERM]
lrusak[m] has quit [Quit: Bridge terminating on SIGTERM]
mrybczyn[m] has quit [Quit: Bridge terminating on SIGTERM]
yudjinn[m] has quit [Quit: Bridge terminating on SIGTERM]
patersonc[m] has quit [Quit: Bridge terminating on SIGTERM]
gstinocher[m] has quit [Quit: Bridge terminating on SIGTERM]
Saur[m] has quit [Quit: Bridge terminating on SIGTERM]
static_rocket has quit [Quit: Bridge terminating on SIGTERM]
Ablu[m] has quit [Quit: Bridge terminating on SIGTERM]
DasChaos[m] has quit [Quit: Bridge terminating on SIGTERM]
ejoerns[m] has quit [Quit: Bridge terminating on SIGTERM]
lorenzog[m] has quit [Quit: Bridge terminating on SIGTERM]
ebilizbelaziz[m] has quit [Quit: Bridge terminating on SIGTERM]
KareemZarka[m] has quit [Quit: Bridge terminating on SIGTERM]
mborzecki has quit [Quit: Bridge terminating on SIGTERM]
p34nuts[m] has quit [Quit: Bridge terminating on SIGTERM]
kayterina[m] has quit [Quit: Bridge terminating on SIGTERM]
TRO[m] has quit [Quit: Bridge terminating on SIGTERM]
Entei[m] has quit [Quit: Bridge terminating on SIGTERM]
phako[m] has quit [Quit: Bridge terminating on SIGTERM]
Francesco[m] has quit [Quit: Bridge terminating on SIGTERM]
baeruhne[m] has quit [Quit: Bridge terminating on SIGTERM]
glembo[m] has quit [Quit: Bridge terminating on SIGTERM]
Finn[m] has quit [Quit: Bridge terminating on SIGTERM]
tomzy_0[m] has quit [Quit: Bridge terminating on SIGTERM]
suwako[m] has quit [Quit: Bridge terminating on SIGTERM]
linex[m] has quit [Quit: Bridge terminating on SIGTERM]
arlort[m] has quit [Quit: Bridge terminating on SIGTERM]
HenkMedenblik[m] has quit [Quit: Bridge terminating on SIGTERM]
NiteshD[m] has quit [Quit: Bridge terminating on SIGTERM]
banditopazzo[m] has quit [Quit: Bridge terminating on SIGTERM]
tenko[m] has quit [Quit: Bridge terminating on SIGTERM]
berton[m] has quit [Quit: Bridge terminating on SIGTERM]
osteoblast22[m] has quit [Quit: Bridge terminating on SIGTERM]
argonautx[m] has quit [Quit: Bridge terminating on SIGTERM]
derinachan[m] has quit [Quit: Bridge terminating on SIGTERM]
perceval[m] has quit [Quit: Bridge terminating on SIGTERM]
glgspg[m] has quit [Quit: Bridge terminating on SIGTERM]
VasylVavrychuk[m has quit [Quit: Bridge terminating on SIGTERM]
Mickal[m] has quit [Quit: Bridge terminating on SIGTERM]
abbasalichezgi[m has quit [Quit: Bridge terminating on SIGTERM]
ramacassis[m] has quit [Quit: Bridge terminating on SIGTERM]
hpsy[m] has quit [Quit: Bridge terminating on SIGTERM]
<JaMa>
ecdhe: maybe take this opportunity to set regular PREMIRROR and let bitbake fetcher do it's job better, instead of fetching whole downloads directory before the build
Perflosopher has quit [Ping timeout: 240 seconds]
khem has joined #yocto
<rburton>
yeah, agreed. make that tarball a proper mirror and you'll be good to go.
shoragan[m] has joined #yocto
yudjinn[m] has joined #yocto
kayterina[m] has joined #yocto
Salamandar has joined #yocto
barath has joined #yocto
patersonc[m] has joined #yocto
esben[m] has joined #yocto
Ablu[m] has joined #yocto
TRO[m] has joined #yocto
ericson2314 has joined #yocto
<rburton>
if you want a way for offline builds then a kas overlay that just does a fetchall will be trivial
static_rocket has joined #yocto
DasChaos[m] has joined #yocto
lrusak[m] has joined #yocto
ebilizbelaziz[m] has joined #yocto
mrybczyn[m] has joined #yocto
p34nuts[m] has joined #yocto
gstinocher[m] has joined #yocto
<ecdhe>
The premirror looks like I need to know the original URL and then host the file at some variant of it
ramacassis[m] has joined #yocto
Entei[m] has joined #yocto
ejoerns[m] has joined #yocto
phako[m] has joined #yocto
Saur[m] has joined #yocto
KareemZarka[m] has joined #yocto
VasylVavrychuk[m has joined #yocto
<rburton>
if your tarball is good for DL_DIR then it's most of the way towards being a premirror
<ecdhe>
I'm trying to count the files now but it seems like a lot of work to get these all moved into a directory structure that a PREMIRROR can seamlessly fetch.
osteoblast22[m] has joined #yocto
<ecdhe>
rburton: so there's hope?
<rburton>
the only difference is that git clones are in tarballs
baeruhne[m] has joined #yocto
HenkMedenblik[m] has joined #yocto
<rburton>
easiest way is to refetch the world with BB_GENERATE_MIRROR_TARBALLS="1" set
linex[m] has joined #yocto
lorenzog[m] has joined #yocto
arlort[m] has joined #yocto
<ecdhe>
rburton: this is fine but some of the sumo assets are not longer hosted
banditopazzo[m] has joined #yocto
<ecdhe>
sorry for using sumo
d-s-e has joined #yocto
glgspg[m] has joined #yocto
<rburton>
use the yocto mirror, or your own existing dldir as a premirror
tomzy_0[m] has joined #yocto
<ecdhe>
I like that idea
Finn[m] has joined #yocto
mborzecki has joined #yocto
Francesco[m] has joined #yocto
suwako[m] has joined #yocto
glembo[m] has joined #yocto
derinachan[m] has joined #yocto
sakoman has joined #yocto
berton[m] has joined #yocto
tenko[m]1 has joined #yocto
<rburton>
if external tarballs have moved (which does happen), i'd recommend fixing the recipes to get the right tarballs instead of relying on a mirror
Perflosopher has joined #yocto
NiteshD[m] has joined #yocto
argonautx[m] has joined #yocto
perceval[m] has joined #yocto
Mickal[m] has joined #yocto
abbasalichezgi[m has joined #yocto
hpsy[m] has joined #yocto
rfs613 has quit [Ping timeout: 268 seconds]
vladest has quit [Ping timeout: 268 seconds]
<JaMa>
premirror is most useful recently for those upstream git repos deleting and renaming branches, yes it should be fixed in recipes, but with premirror it at least wont start failing a day before release and you can fix it when you have time
rfs613 has joined #yocto
kscherer has joined #yocto
amitk_ has quit [Ping timeout: 268 seconds]
thomasd13 has quit [Ping timeout: 240 seconds]
crazy_imp has joined #yocto
vladest has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<ecdhe>
rburton: the payoff for me is if I can trigger a yocto build from a singal command in a uninitialized environment I can move the job to a threadripper... kernel builds are sub 30 seconds there as opposed to 30 minutes on my i7
<JaMa>
sub 30 seconds? either your defconfig is very short or you have some special threadripper :) my 3970 linux-yocto*/do_compile
<eddy_>
Hi, I have a question: How can i specify a buildtime dependecy for kernel modules in yotco? I have module A that has a header with functions that are exported and a module B that shouldbe able to include the header. I cannot find anything in the docu about kernel module dependencies
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
mvlad has quit [Remote host closed the connection]
<rfs613>
eddy_: typically each module would have two recipies, one to install the header, and one to build the module. Then you can set the dependencies of B on the headers provided by A.
<rburton>
eddy_: just make the recipe install headers into the sysroot as usual, and then depend on that recipe
<rburton>
a recipe installing headers is just a recipe installing headers, nothing special to do just because its a kernel module
<rfs613>
i suspect you don't need separate packages, just have B depend on A would probably work
dmoseley has joined #yocto
<rfs613>
to continue the previous example, cryptodev-module then has DEPENDS += "cryptodev-linux"
alessioigor has quit [Quit: alessioigor]
<eddy_>
thanks i try it out :)
<nerdboy>
so i masked gcc-13 and rebuilt full toolchain set with gcc-12 and yocto seems happy again
<nerdboy>
*at least as happy as before on meta-tegra kirkstone lts branches
amitk_ has quit [Ping timeout: 240 seconds]
<zelgomer>
with reference to the downloads dir, how is bitbake supposed to handle name collisions, such as when two recipes have a SRC_URI that fetches different files from different hosts but with the same base filename?
<vmeson>
mischief: I don't think so, see your log: ../../../../../../work-shared/gcc-11.3.0-r0/gcc-11.3.0/gcc/c/gimple-parser.c:381:1: internal compiler error: Bus error
<vmeson>
it's the first match when searching for "error:" which works > 98% of the time.
<ecdhe>
LetoThe2nd: where is your new position?
<vmeson>
Is an ICE: Bus error usually bad hardware as suggested by Google ?
<mischief>
ah, heck. i checked the kernel log and there are memory hw errors, and i also checked the ec2 console and got a message about the hw being retired :)
<mischief>
i just made a new instance, so let's see how that goes
<mischief>
i'm trying to evaluate if a new instance type can make our build faster
<vmeson>
mischief: cool. We don't want any real rare ICE toolchain errors to track down!
<mischief>
so i'm just spinning up instances and building poky with default settings
<vmeson>
mischief: that'll be interesting data.
<mischief>
c7g.metal (graviton3) did a build in ~15 minutes
<mischief>
now i try c6gd.metal (graviton2) which has local nvme
<mischief>
the problem is we build multiple MACHINEs in parallel without multiconfig and some people complain it takes too long
<mischief>
i wonder if it would be better to just have a smaller instance per MACHINE instead of big beefy instances with parallel builds inside
florian_kc has joined #yocto
seninha has joined #yocto
seninha has quit [Remote host closed the connection]
seninha has joined #yocto
nerdboy has quit [Remote host closed the connection]
nerdboy has joined #yocto
nerdboy has joined #yocto
nerdboy has quit [Changing host]
<khem>
RP: OK then I can drop it. Sadly it will need gcc 13 patch conflicts to be resolved
florian_kc has quit [Ping timeout: 276 seconds]
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
kscherer has quit [Quit: Konversation terminated!]