wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
user_123 has quit [*.net *.split]
wyre has quit [*.net *.split]
Pierre-jeanTexie has quit [*.net *.split]
moto_timo[m] has quit [*.net *.split]
fancer has quit [*.net *.split]
dl9pf has quit [*.net *.split]
hmw[m] has quit [*.net *.split]
elfenix|cloud has quit [*.net *.split]
xtopher_ has quit [*.net *.split]
rmmr has quit [*.net *.split]
barath has quit [*.net *.split]
Ch^W has quit [*.net *.split]
LocutusOfBorg has quit [*.net *.split]
mvlad has quit [*.net *.split]
LocutusOfBorg has joined #yocto
Ch^W has joined #yocto
user_123 has joined #yocto
fancer has joined #yocto
elfenix|cloud has joined #yocto
Pierre-jeanTexie has joined #yocto
wyre has joined #yocto
xtopher_ has joined #yocto
dl9pf has joined #yocto
rmmr has joined #yocto
moto_timo[m] has joined #yocto
barath has joined #yocto
hmw[m] has joined #yocto
Saur[m] has quit [*.net *.split]
lexano[m] has quit [*.net *.split]
falk0n[m] has quit [*.net *.split]
behanw[m] has quit [*.net *.split]
khem has quit [*.net *.split]
karl has quit [*.net *.split]
warthog9 has quit [*.net *.split]
kmaincent has quit [*.net *.split]
ndec has quit [*.net *.split]
karl has joined #yocto
ndec_ has joined #yocto
kmaincent has joined #yocto
Saur[m] has joined #yocto
lexano[m] has joined #yocto
khem has joined #yocto
behanw[m] has joined #yocto
falk0n[m] has joined #yocto
warthog9 has joined #yocto
goliath has joined #yocto
dev1990 has joined #yocto
<JosefHolzmayr[m]>
yo dudX
dev1990 has quit [Quit: Konversation terminated!]
Guest58 has joined #yocto
zyga-mbp has joined #yocto
wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
Guest58 has quit [Quit: Client closed]
ant__ has quit [Quit: Leaving]
rob_w has joined #yocto
rfuentess has joined #yocto
frieder has joined #yocto
gsalazar_ has joined #yocto
gsalazar_ is now known as gsalazar
mckoan|away is now known as mckoan
<mckoan>
good morning
Johnsv has joined #yocto
<erbo>
morning!
goliath has quit [Quit: SIGSEGV]
eduardas has joined #yocto
<wCPO>
Is there any difference between RECIPE_SYSROOT and STAGING_DIR_HOST?
<Johnsv>
Hi, is it possible to build with yocto a target image for x86 which includes a cross-toolchain for another architecture, e.g. ARM as well as inside this same target image an APT installation that allows to install -dev packages for this ARM arch, provided by a yocto package feed/repository?
prabhakarlad has joined #yocto
leon-anavi has joined #yocto
<RP>
Johnsv: multiconfig would let you put an arm image inside an x86 one. We don't have the compiler setup like that out the box in OE-Core but I know it can be done as I've done it before a while ago
BCMM has joined #yocto
<Johnsv>
RP: thanks, I will have a look into multiconfig
florian has joined #yocto
goliath has joined #yocto
wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
m4ho has quit [Ping timeout: 245 seconds]
<rburton>
hm looks like recent gatesgarth commits just broke external-arm-toolchain
m4ho has joined #yocto
jonesv[m] has quit [Quit: You have been kicked for being idle]
janvermaete[m] has joined #yocto
mckoan is now known as mckoan|away
florian_kc has joined #yocto
awafaa has quit []
awafaa has joined #yocto
GillesM has joined #yocto
<RP>
rburton: that doesn't sound good :(
<rburton>
not sure how, nothing landed that would obviosly do that
<rburton>
maybe just a glitch in the CI
ernstp has joined #yocto
rsalveti has quit []
<ernstp>
Hmm I seem to get a new 80MB bb_cache.dat.123124124... for every build almost.
rsalveti has joined #yocto
<ernstp>
the one in build/tmp/cache/default-glibc/MACHINE/x86-64/
jwillikers has joined #yocto
<rburton>
thats the parsed recipe data
<rburton>
thus the 'cache'
<ernstp>
I thought that was in build/cache/
<RP>
ernstp: build/cache has the parsed metadata, top level cache has other caches which aren't as transient
<rburton>
bah i was close
<ernstp>
so build/tmp/cache/ is supposed to be very transient?
<RP>
rburton: you were right I think, I'm just writing things that don't quite make sense :/
<RP>
ernstp: as transient as "tmp" is
<RP>
build/tmp/cache has the parsed metadata, top level build/cache has other caches which aren't as transient
<RP>
is what I was trying to say and failing
<ernstp>
trying to optimize an automatic builder
<ernstp>
tried to save some time by not nuking all of build/tmp/ between every build...
<rburton>
inheriting rm_work makes the deletes happen during the build in the background, which saves a lot of time
<rburton>
especially if you have a long commit timeout on the filesystem, as you can delete stuff before it gets written
<ernstp>
interesting!
NishanthMenon_ has quit []
NishanthMenon_ has joined #yocto
wwilly has quit [Ping timeout: 265 seconds]
* RP
hates rm_work
Tyaku has joined #yocto
Tyaku has quit [Client Quit]
Tyaku has joined #yocto
<Tyaku>
Hi, Did you know if it's possible to make a receipe to build "GN" based project ?
<qschulz>
Tyaku: there are some recipes available to build chromium which is gn based
<Tyaku>
3 Months ago he said "This task is blocking on adding the GN capability in yocto which is being currently handled as task: OSTC/OHOS/meta-ohos#53 (closed). So, this task would be parked in backlog and would be taken up once GN is available as a part of yocto project."
<ernstp>
hmm, enabling rm_work seems to have made a build error (correctly) surface that had been hidden forever... :-)
<Tyaku>
rburton: My objective is to create a recipe to build the Matter (connectedhomeip) library and then to create a custom software that use this library.
tgamblin has joined #yocto
<Tyaku>
rburton: Do you think in the future, something "generic" will come as part of Yocto project to create receipe with GN based project ?
<rburton>
Tyaku: if there's a need, sure
<Tyaku>
rburton: What does your recipe exactly ? It build the GN tool ?
<rburton>
yes
<rburton>
your recipe then depends on gn-native and you write do_compile etc
<Tyaku>
Oh ok
<Tyaku>
And what is the difference with the class method that i linked before ?
<rburton>
i'm not 100% sure that the gn class in that layer works with all gn using projects
<rburton>
maybe it does, and you should use that
wwilly has joined #yocto
<Tyaku>
rburton, using your method, do you have an exemple of a recipe for a project that depends on gn-native and define it's own do_compile etc ?
<rburton>
we use it in hafnium, but that ships with a makefile that does everything so it just calls make
<rburton>
you'll have to read the build instructions for what youre building
creich has quit [Ping timeout: 245 seconds]
xmn has quit [Ping timeout: 252 seconds]
otavio has quit [Remote host closed the connection]
dagmcr has quit []
dagmcr has joined #yocto
otavio has joined #yocto
Guest1 has joined #yocto
manuel1985 has joined #yocto
ngoub has joined #yocto
<ngoub>
Hello
<ngoub>
I find the "root" cause of the VIRTUAL-RUNTIME_init_manager error
<ngoub>
I had in my local.conf : BBCLASSEXTEND = "native nativesdk"
<ngoub>
when I displayed DISTRO_FEATURES in packagegroup.class, I got something strange DISTRO_FEATURES= ipv6 opengl x11 xattr pulseaudio gobject-introspection-data ldconfig
Guest1 has quit [Quit: Client closed]
<rburton>
what did you expect to happen when you put BBCLASSEXTEND into local.conf?
<ngoub>
I don't know, may be it is the result of some testing
<Guest1124>
I'm have a do_fetch failure I don't understand in Dunfell 3.1.7. I'm getting the error: "ERROR: go-systemd-4+gitAUTOINC+b4a58d9518-r0 do_fetch: Fetcher failure: Unable to find revision b4a58d95188dd092ae20072bac14cece0e67c388 in branch master even from upstream
<Guest1124>
ERROR: go-systemd-4+gitAUTOINC+b4a58d9518-r0 do_fetch: Fetcher failure for URL: 'git://github.com/coreos/go-systemd.git'. Unable to fetch URL from any source."
<Guest1124>
I went to the upstream and verified that b4a58d95188dd092ae20072bac14cece0e67c388 does exist on master.
<Guest1124>
I'm at a lost as to what to check next.
rob_w has quit [Remote host closed the connection]
<Guest1124>
I've built this image many times, but just recently cleared my caches.
<Tyaku>
Guest1124: I'm not "PRO" in yocto, but i already get this kind of errors. Sometimes it's because the fetch with GIT use SSH instead of HTTP. So if you don't have an account correctly configured on the GIT provider (ex: GitHub) then SSH fetch won't work.
<Tyaku>
Guest1124: Again, Here this is an example where we specify the HTTP protocol in the recipe: "SRC_URI = "gitsm://github.com/openthread/ot-br-posix.git;protocol=https;branch=main"" (it's a gitsm for submodules)
<Guest1124>
@Tyaku Yes except that I do have a github account and I was able to fetch many other components during the build. This is the only one failing so far. But, I'll try your suggestion.
Little_rabbit has joined #yocto
whuang0389 has joined #yocto
<Guest1124>
@Tyaku No luck. I still get the do_fetch failure using the https. ERROR: go-systemd-4+gitAUTOINC+b4a58d9518-r0 do_fetch: Fetcher failure: Unable to find revision b4a58d95188dd092ae20072bac14cece0e67c388 in branch master even from upstream
<Guest1124>
ERROR: go-systemd-4+gitAUTOINC+b4a58d9518-r0 do_fetch: Fetcher failure for URL: 'gitsm://github.com/coreos/go-systemd.git;protocol=https;branch=master'. Unable to fetch URL from any source.
<whuang0389>
is there a way to check which recipe is brining in another recipe? I'm trying to remove busybox but doing it via image_install_remove doesnt seem to work, so Im thinking of bbappending the recipe that is bringing it in
camus has quit [Quit: camus]
kiran has joined #yocto
<Tyaku>
Guest1124: So i don't know what happens, I can only confirm what you said: I try to clone the repository and checkout b4a58d95188dd092ae20072bac14cece0e67c388 and it works. The question is: What happens during the do_fetch(). Maybe a Yocto Pro will better help you
<JosefHolzmayr[m]>
whuang0389: bitbake -g your image, then inspect the resulting depends.dot files. use a textviewer and/or grep
<Guest1124>
@Tyaku Thanks for the help! Yes, I had done the same experiment - clone and checkout - and it succeeded for me also.
<Little_rabbit>
Hey, is is possible to define a function within the local.conf file? I need to quick test something and was hoping to define a function in conf/local.conf and add in to ROOTFS_POSTINSTALL_COMMAND.
<Little_rabbit>
Don't hate me... :(
<zeddii>
Guest1124: assuming you are getting go-systemd from meta-virt, and not somewhere else, the meta-virt branch you are building is out of date.
<Little_rabbit>
It's just so convenient for quick validations...
<qschulz>
Little_rabbit: just add it to the image recipe, directly in it or via a bbappend
<Little_rabbit>
qschulz: Fair. I guess then I risk commiting the change :). But thanks, makes sense
<qschulz>
Guest1124: I'd probably triple check what zeddii said, but I assume go-systemd just moved from master to main for the principal branch
<RP>
Little_rabbit: you can add a class to classes/XXX and INHERIT it from local.conf
<qschulz>
Little_rabbit: you can create a layer quickly with bitbake-layers create-layer and then bitbake-layers add-layer IIRC
<zeddii>
it did, and we've update in meta-virt, with a backport to dunfell
<Guest1124>
@zeddii Yes, I am getting it from meta-virtualization. However, the SRC_URI for go-systemd does seem to be valid. It exists in github and the specific commit exists also.
<RP>
Little_rabbit: bitbake will look at a classes directory alongside conf/
<qschulz>
Guest1124: it exists but not in the master branch
<qschulz>
since the master branch is probably gone now
<Guest1124>
@zeddi Hmmm. Okay. Let me noodle with that.
<qschulz>
RP: though having an INHERIT like that will make all recipes being reparsed right? so anmy change to the class will result in long parsing time?
splatch has joined #yocto
<RP>
qschulz: that could be an issue, I was just answering the question
<Guest1124>
@zeddi and @qschulz Thanks. My fetch is succeeding now. I'm not sure how I missed the branch change. I must have assumed the default was master. Anyhow, thenks for setting me straight.
<qschulz>
Guest1124: alas go-systemd is not the only one having done that and some repos still change every now and then
<qschulz>
quite a pain
<qschulz>
especially for people on old unmaintained branches
<qschulz>
but nothing we can do for them as they're EOL :)
<Guest1124>
@qshulz for most of my work, I keep up to date with the latest Dunfell. For this particular task, I had to duplicate a build from the past.
<qschulz>
Guest1124: Dunfell is maintained, so it was just a forgotten pull, but some branches (zeus, warrior, thud, rocko, etc) won't ever receive those patches to fix the master->main change
frieder has quit [Remote host closed the connection]
<Guest1124>
@qschulz Understood. I need stability because I maintain many platforms. I really appreciate the Dunfell LTS and I'll jump to the next one whenever Dunfell goes EOL.
Guest1124 has quit [Quit: Client closed]
Guest1176 has joined #yocto
splatch has quit [Remote host closed the connection]
Guest1176 has quit [Client Quit]
eduardas has quit [Quit: Konversation terminated!]
Tyaku has quit [Quit: Lost terminal]
dev1990 has joined #yocto
mabnhdev has joined #yocto
mabnhdev has quit [Remote host closed the connection]
florian_kc has quit [Ping timeout: 268 seconds]
kiran has quit [Quit: Konversation terminated!]
kiran has joined #yocto
whuang0389 has quit [Quit: Client closed]
Little_rabbit has quit [Quit: Client closed]
whuang0389 has joined #yocto
ngoub has quit [Remote host closed the connection]
goliath has joined #yocto
<RP>
JPEW: I've just noticed something very strange. We may have reproducibility at the package level but our outhashes are varying an awful lot
<RP>
JPEW: an easy example is to add do_install += " " to the bash recipe and watch the outhash for do_package. I think its due to the time clamps used on the packages but not the sstate archives
<RP>
we'd get way better hashequiv results if we fix that
<fray>
would this be like some of the other variable sanitation we did a few years back that fixed a lot of hash mismatches? (before has equivalency)
<RP>
fray: looks like a date stamp issue rather than anything else
<fray>
Ohh ok, so different then, not variable contents (extra spaces and such, but other side effects)
<RP>
fray: yes, task output effects
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zyga-mbp has joined #yocto
zyga-mbp has quit [Client Quit]
florian has quit [Quit: Ex-Chat]
amitk has quit [Ping timeout: 252 seconds]
rfuentess has quit [Remote host closed the connection]
zyga-mbp has joined #yocto
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<JPEW>
RP: We should clamp the mtime on the sstate archives and the outhash calculation (the two are independent IIRC)
<JPEW>
?
smurray has quit []
zyga-mbp has joined #yocto
smurray has joined #yocto
yates has joined #yocto
<yates>
when i run "bitake gcc-cross-csky", i find a Makefile, <build>/tmp/work/x86_64-linux/gcc-cross-csky/10.3.0-r0/gcc-10.3.0/build.x86_64-linux.csky-poky-linux/csky-poky-linux/libgcc/Makefile
zpfvo1 has quit [Remote host closed the connection]
<yates>
since libgcc is a subdirectory of the gcc package, and there is no "gcc" folder inside build.x86_64-linux.csky-poky-linux, it must be copied from somewhere, right? where is this coming from?
kiran has quit [Ping timeout: 268 seconds]
kiran has joined #yocto
<rburton>
that's the build tree, not the source tree
<rburton>
gcc builds out-of-tree
<rburton>
out-of-source-tree
<yates>
ok.
<yates>
my goal is to find how crti.S is being compiled for the gcc-cross-csky
GillesM has quit [Remote host closed the connection]
<yates>
correction: my true goal is to patch this build to get the proper definitions in
<yates>
but to patch i need to find which recipe is responsible for it
<yates>
the crti.o that is being used in csky-poky-linux-gcc is wrong - i need to find out where that is getting build and patch it
<rburton>
the gcc source is in tmp/work-shared
zyga-mbp has quit [Ping timeout: 265 seconds]
zyga-mbp has joined #yocto
<yates>
rburton: is it not true that yocto/oe builds gcc for the host machine (in my case x86_64) as well as the cross-gcc that runs on the host machine and generates files (executables) which will run on the target machine?
<yates>
i do not understand where/how the compilation of the crti.S is done for the cross-gcc.
mranostaj has quit [Ping timeout: 265 seconds]
<rburton>
yates: yocto never builds a native compiler, it uses the host to build a cross
<yates>
ok
<yates>
i still do not understand where/how the compilation of the crti.S is done for the cross-gcc.
<yates>
there is meta/recipes-devtools/gcc/gcc_{pv}.bb, and there is meta/recipes-devtools/gcc/gcc-cross_{pv}.bb. which one builds the cross compiler?
<RP>
JPEW: I'm wondering if we should just make do_package clamp the mtime
<yates>
i also do not understand why there are separate ligcc-xyz.bb recipes. isn't libgcc built as part of gcc?
<RP>
yates: we build one cross compiler for the architecture, we have to build a libgcc per tune
<agherzan>
Partner said I need to wash it first but it's just to cool
angolini has joined #yocto
florian_kc has joined #yocto
<marc1>
Has anyone ever had an issue when building a kernel (bitbake virtual/kernel) where for some reason only one CPU is used troughout the build? Looking at the logs, I see that '-j 20' is used with make, but for some reason a single gcc process is started. The other recipes do not seem to have this issue.
<rburton>
maybe its a custom kernel and someone broke the build?
<marc1>
It's a linux-yocto kernel if that makes any difference...
<rburton>
agherzan: +1 to that
kiran has quit [Ping timeout: 268 seconds]
<RP>
agherzan: nice, I got a burgundy colour one (since I'm YP Compat!), been too warm to wear so far though
arunss has joined #yocto
<ndec_>
agherzan: awesome ;)
<ndec_>
i have them in too many colors.. and it is indeed causing some troubles at home ;)
<khem>
mine got confiscated by my son
<agherzan>
@RP I wanted burgundy but it didn't pass the family vote.
<ndec_>
my sons has his too.. ;)
roussinm has joined #yocto
<agherzan>
Sadly you don't do babies
<agherzan>
I mean baby sizes - to avoid confusion :)
<ndec_>
well, i could include babies stuff.. but it didn't feel appropriate..
<ndec_>
they make bodysuits and small t-shirt )
<JPEW>
RP: Hmm... that might be appliciable to any sstate task?
<JPEW>
of course... I don't think do_package is actually an sstate task is it
<agherzan>
@ndec_ cute
ernstp has quit []
ernstp has joined #yocto
<arunss>
I have a custom target with 64-bit kernel and 32-bit userspace using multilib. Target successfully builds, however SDK build fails trying to build userspace packages in 64-bit. Is there a way to determine why SDK builds 64-bit or set it to build only 32-bit packages?
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #yocto
darknighte has quit []
darknighte has joined #yocto
wwilly has quit [Ping timeout: 265 seconds]
mranostaj has joined #yocto
mattsm is now known as Guest4038
Guest4038 has quit [Killed (iridium.libera.chat (Nickname regained by services))]
mattsm has joined #yocto
mattsm has quit [Read error: Connection reset by peer]
ldts has quit []
mattsm has joined #yocto
paulbarker has quit []
ldts has joined #yocto
paulbarker has joined #yocto
florian_kc has quit [Ping timeout: 268 seconds]
<RP>
JPEW: yes, do_package is
florian_kc has joined #yocto
<JPEW>
RP: Perhaps all sstate tasks should clamp the mtime in the input directory before creating the sstate archive? What could go wrong...
kiran has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<RP>
JPEW: I'm not sure I like that idea
<RP>
JPEW: although it does have a certain simplicity to it
<JPEW>
RP: Ya, I'm not sure either.... but I could certially see a future where we manually end up adding to every sstate task for better repro/hashequiv reasons
<JPEW>
RP: Seems fine to add it just to do_package for now maybe with a note that we may need to make it more generic in the future
<RP>
JPEW: adding just to do_package isn't straightforward and I think all sstate tasks will have this issue
<RP>
JPEW: I've been playing and it isn't simple
zyga-mbp has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
goliath has quit [Quit: SIGSEGV]
zyga-mbp has joined #yocto
splatch has joined #yocto
<splatch>
hello, I ran into something unexpected and I am not quite sure what issue it really is. Is it host hardware or build issue: 'Creating filesystem with 2097152 4k blocks and 1048576 inodes' later on 'Writing superblocks and filesystem accounting information: mkfs.ext4: Input/output error while writing out and closing file system'.
zyga-mbp has quit [Read error: Connection reset by peer]
pgowda has quit [Quit: Connection closed for inactivity]
gsalazar has quit [Remote host closed the connection]
gsalazar has joined #yocto
<yates>
rburton: you said the other day that gcc-cross*.bb builds the cross compiler. what id gcc*.bb for?
<yates>
is
<yates>
rburton: you stated today: "the gcc source is in tmp/work-shared". that is true - i can see that. so what of it? are you saying this is where i should patch files?
<RP>
yates: isn't crti.S compiled by glibc ?
<RP>
yates: grepping in tmp/sstate-control/* suggests the file is part of glibc
<yates>
RP: since it is a part of the libgcc submake, i would think it is compiled in the libgcc build.
<yates>
what is tmp/sstate-control for?
<RP>
yates: it contains the manifests used by sstate to control which files get installed where in sysroots
<RP>
ant__: those definitions aren't identical, I think it is intended
<RP>
JPEW: this is proving really hard to sort out :(
<ant__>
I first read about this var today, debugging a bogus e2fsprogs.bbappend machine-arch
<JPEW>
RP: Hmm, I guess my initial glance was deceiving
<JPEW>
Whats the difficulty?
<RP>
JPEW: the trouble is we need the on disk files to match what is in sstate else we'll get weird differences in "from sstate" and "not from sstate" builds
<ant__>
RP: on line 13
<ant__>
SSTATE_PKGARCH = "${PACKAGE_ARCH}"
* RP
learnt long ago we don't want to go there even for simple dates
stephano has joined #yocto
<RP>
ant__: right, I'd rather have the duplicate definitions than make the function half compelte though
<ant__>
for the sake of precision, while grepping for it I found references in toaster.bbclass
<ant__>
isn'it deprecated nowadays?
<JPEW>
That's why we can't just clamp the sstate with tar when creating the archive, correct?
<JPEW>
Clamp the mtime that is
<RP>
JPEW: yes, then the two paths differ
<RP>
JPEW: that way lies maddness
<JPEW>
Agrees
<JPEW>
I was thinking we clamp the mtime on the input directories before sstate_install... At least as a test
<RP>
JPEW: sstate_package() is where I think we need to do it, I have some code testing atm
<JPEW>
Sounds reasonable. We can talk at the call tomorrow.
<RP>
JPEW: right, I'll continue to experiment
<RP>
JPEW: just letting you know what I'm finding
<RP>
I'm amazed how painful this is being
otavio has quit [Remote host closed the connection]
xmn has joined #yocto
otavio has joined #yocto
<RP>
JPEW: well, I fixed the timestamp issue. More worryingly, the content of bash's packages keeps changing
<RP>
oh, fun. bash increases a version every time you run make install on it
* RP
should find something else to test with then :/