<LetoThe2nd>
derRichard: dead? you mean... flat-packed?
argonautx has quit [Quit: Leaving]
kscherer has joined #yocto
<derRichard>
LetoThe2nd: :-S
seninha has joined #yocto
leon-anavi has quit [Quit: Leaving]
kroon has quit [Quit: Leaving]
Guest4524 has joined #yocto
<Guest4524>
Good Afternoon! Can anybody tell me how to find out which (main) device-tree file is used in my build?
ardo has quit [Read error: Connection reset by peer]
prabhakarlad has quit [Quit: Client closed]
ardo has joined #yocto
DougC has joined #yocto
DougC has quit [Client Quit]
seninha has quit [Quit: Leaving]
xmn has joined #yocto
ardo has quit [Read error: Connection reset by peer]
seninha has joined #yocto
ardo has joined #yocto
<LetoThe2nd>
*lesigh* trying to build on a relatively cheap v-server, only to find out it doesn't allow modification of mmap_min_addr :-(
sakoman has joined #yocto
ardo has quit [Read error: Connection reset by peer]
<derRichard>
LetoThe2nd: well, you get what you pay for
* derRichard
runs
<LetoThe2nd>
derRichard: guess who kinda saw it coming and signed up for short testing period only. well thats essentially the price of two beers wasted.
ardo has joined #yocto
<LetoThe2nd>
seems like i'll have to bite the bullet and order something bigger.
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
dgriego has joined #yocto
rsalveti has joined #yocto
prabhakarlad has joined #yocto
Schlumpf has quit [Quit: Client closed]
thomasd13 has quit [Ping timeout: 256 seconds]
Schlumpf has joined #yocto
zeddii has quit [Ping timeout: 256 seconds]
zeddii has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
<svuorela_>
hmm.. my image has recently-ish gotten a 35mb go runtime .so file. Can I ask bitbake/yocto/something why this libstd.so is there ?
frieder has quit [Remote host closed the connection]
cambrian_invader has joined #yocto
<neverpanic>
svuorela_: that seems to be the go runtime library.
<neverpanic>
If you have package management enabled on your image, you can ask the package manager why it's installed. How to do that depends on which package manager you use.
roussinm has joined #yocto
<svuorela_>
packagemanagement is not on the device, no.
<svuorela_>
found the offending recipe by grepping.
Guest4524 has quit [Quit: Client closed]
<Saur[m]>
svuorela_: You do not need package management. You can use `oe-pkgdata-util find-path /usr/lib/libstd.so` to ask bitbake what package is responsible for installing a given file. That assumes the package has been built though.
Schlumpf has quit [Quit: Client closed]
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
<zeddii>
RP: for a hung 'initializing tasks" ... should I just rm -rf on tmp, or is there something more intelligent I can do to figure out what's going on ? My googling didn't find me anything useful.
<neverpanic>
That doesn't answer the question which recipe depends on this package, though.
<fray>
zeddii, I will usually use 'ps' and kill all bitbake processes, and I don't usually need to dump tmp
<zeddii>
did that.
<fray>
where I've seen that happen is hit control-c during processing and it left some process or lock file around..
<zeddii>
even nuked some Cooker processes, still sits at 44% and never goes any further
<fray>
I've not seen that behavior.. sorry
otavio has quit [Ping timeout: 255 seconds]
<rburton>
when i see a hang at 44% its because its hitting remote sstate
otavio has joined #yocto
<rburton>
neverpanic: i have a tool i'm literally releasing tomorrow which helps with chasing package level dependencies
DougC has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
<zeddii>
rburton: ahah. could be that then.
nemik has joined #yocto
<zeddii>
so removing my tmp, won't help with that.
<rburton>
if you have remote sstate mirror try commenting it out
<fray>
we've got a case of a circular dependency and right now we kind of worked around it.. but it's apparently complex enough that after a few days we still failed to really understand what is going on.. is your tool help with that, or still a different issue?
<rburton>
nah
<rburton>
basically its a graphical explorer for pkgdata
<rburton>
recipe list, their packages, their metadata and dependencies, and links between
<fray>
the issue appears to basically be kernel depends on the image, the image depends on something which depends on something which depends on something which depends on the kernel
<rburton>
we've hit that in meta-arm with machines which want to use kernels with fitimages that contain initramfs
<rburton>
end up with a big circle of deps
<fray>
rburton that is exactly what this is.. fitimage w/ initramfs
vladest has joined #yocto
<fray>
I was out last week acquiring COVID.. so I left it to others and they made no real progress on understanding it.. looking at the printed logs I didn't make much sense of it either.. :(
<rburton>
or something. i forget because it's not obvious
xmn has joined #yocto
<fray>
what is hte wic.nopt?
seninha has quit [Quit: Leaving]
<zeddii>
looks like it was the hashserv for me. commented it out for now.
<fray>
hashserv db is in the cache directory. instead of commenting it out, you can just wipe the DB.. it'll cause a slightly longer build, but should be able to resume.. I think
<rburton>
fray: nopt is just a dumb class to strip a partition table off a disk image
goliath has quit [Quit: SIGSEGV]
<RP>
zeddii: was that a local hashserv? Did the DB become huge? or a slow remote?
<RP>
zeddii: 44% on task init is definitely hashequiv though
Wouter01001 has quit [Remote host closed the connection]
tangofoxtrot has quit [Remote host closed the connection]
Wouter01001 has joined #yocto
tangofoxtrot has joined #yocto
mitch has joined #yocto
vmeson has quit [Quit: Konversation terminated!]
vmeson has joined #yocto
mitch has quit [Quit: Leaving]
rfuentess has quit [Remote host closed the connection]
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
<zeddii>
RP: it was the default typhoon one. did the url change for it ? I recall someone saying something about that (as part of the -stable releases, etc
<zeddii>
maybe my upstream hashserv is now invalid.
<RP>
halstead: I'm wondering if the hashserv on the controller was the source of the web issues?
<RP>
halstead: I wonder if we need to clean out that DB a bit?
<RP>
zeddii: I'm guessing the server has some issues :/
dev1990 has quit [Quit: Konversation terminated!]
<DougC>
is there anyway to call a custom task in the native context such that the CC/CXX variables are set to the host compiler?
Wouter01001 has quit [Read error: Connection reset by peer]
Wouter01001 has joined #yocto
dgriego_ has joined #yocto
dgriego has quit [Ping timeout: 276 seconds]
<RP>
DougC: just add a task, it should just work?
<DougC>
RP: i did that but CC/CXX are set to the aarch64 compiler
<DougC>
i need to precompile a host tool
<DougC>
before compiling for the target
Tyaku- has joined #yocto
<Tyaku->
I finally found my problem. The problem was: Using the same boot files, the UART console was not enabled when booting the RPI by PXE, but it was OK when booting on SDCARD ... The problem was not related to yocto ... It's something like a "feature" in PXE booting ... The RPI firmware only read the first 0x1000 bytes of config.txt when PXE booting
<Tyaku->
... And as this file originally contains a lot of comments, It was not reading the lines to enable uart [...]
<DougC>
ok. well i exported the CC and CXX flags in the task and cleared CFLAGS/CXXFLAGS which gave the expected result
<RP>
DougC: sorry, I thought you were saying this was in the native context. You want BUILD_CC/BUILD_CXX then
Wouter01001 has quit [Read error: Connection reset by peer]
Wouter01001 has joined #yocto
amitk has quit [Ping timeout: 246 seconds]
lzusgx has joined #yocto
<DougC>
RP: thanks. i ended up exporting those variables in the specific task
dev1990 has joined #yocto
<diamondman>
I created a recipe to hold my .proto files and export them to other recipe's sysroot. I was able to get the proto files copied to `sysroot-destdir/usr/share/proto/` by appending to `SYSROOT_DIRS`, but when another recipe depends on my proto recipe, I do not see the .proto files being copied to the sysroot of the 2nd recipe. Am I missing something else to actually get the files to other recipes? Note I am running Rocko.