GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
goliath has quit [Quit: SIGSEGV]
jclsn has quit [Quit: Ping timeout (120 seconds)]
jclsn has joined #yocto
vmeson has quit [Quit: Konversation terminated!]
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jclsn has quit [Ping timeout: 240 seconds]
jclsn has joined #yocto
ar__ has quit [Ping timeout: 250 seconds]
jclsn0 has joined #yocto
lowfi has joined #yocto
jclsn has quit [Ping timeout: 240 seconds]
jclsn0 is now known as jclsn
Vonter has joined #yocto
amitk has joined #yocto
warthog9 has quit [Quit: Leaving]
warthog9 has joined #yocto
dgriego_ has quit [Read error: Connection reset by peer]
dgriego has joined #yocto
Wouter0100 has quit [Remote host closed the connection]
Wouter0100 has joined #yocto
davidinux has joined #yocto
davidinux has quit [Ping timeout: 240 seconds]
davidinux has joined #yocto
lowfi has quit [Quit: Leaving]
frieder has joined #yocto
mvlad has joined #yocto
tlwoerner has quit [Ping timeout: 240 seconds]
sstiller has joined #yocto
jonmason has quit [*.net *.split]
flynn378 has quit [*.net *.split]
rhadye has quit [*.net *.split]
kergoth has quit [*.net *.split]
madisox has quit [*.net *.split]
moto-timo has quit [*.net *.split]
_wmills has quit [*.net *.split]
dmoseley has quit [*.net *.split]
marc1 has quit [*.net *.split]
lexano has quit [*.net *.split]
Lihis has quit [*.net *.split]
tangofoxtrot has quit [*.net *.split]
JaMa has quit [*.net *.split]
rfried has quit [*.net *.split]
bantu has quit [*.net *.split]
geoffhp has quit [*.net *.split]
LetoThe2nd has quit [*.net *.split]
Piraty has quit [*.net *.split]
xperia64 has quit [*.net *.split]
ldericher has quit [*.net *.split]
sgw has quit [*.net *.split]
kanavin has quit [Read error: Connection reset by peer]
kanavin has joined #yocto
dmoseley has joined #yocto
_wmills has joined #yocto
lexano has joined #yocto
marc1 has joined #yocto
tangofoxtrot has joined #yocto
Lihis has joined #yocto
rfried has joined #yocto
geoffhp has joined #yocto
JaMa has joined #yocto
bantu has joined #yocto
xperia64 has joined #yocto
LetoThe2nd has joined #yocto
Piraty has joined #yocto
sgw has joined #yocto
ldericher has joined #yocto
flynn378 has joined #yocto
kergoth has joined #yocto
jonmason has joined #yocto
rhadye has joined #yocto
madisox has joined #yocto
moto-timo has joined #yocto
tlwoerner has joined #yocto
Vonter has quit [Ping timeout: 256 seconds]
mckoan|away is now known as mckoan
<mckoan>
good morning
xmn has quit [Ping timeout: 250 seconds]
Vonter has joined #yocto
tlwoerner has quit [Ping timeout: 256 seconds]
goliath has joined #yocto
<LetoThe2nd>
yo dudX and mckoans
tlwoerner has joined #yocto
zpfvo has joined #yocto
kroon has joined #yocto
Vonter has quit [Ping timeout: 256 seconds]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
Schlumpf has joined #yocto
Vonter has joined #yocto
<jclsn>
Morning
<qschulz>
howdy
Vonter has quit [Read error: Connection reset by peer]
Vonter has joined #yocto
leon-anavi has joined #yocto
smsm has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
GNUmoon has quit [Quit: Leaving]
GNUmoon has joined #yocto
olani has joined #yocto
zyga has joined #yocto
<zyga>
good morning
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
florian has joined #yocto
Schlumpf has quit [Ping timeout: 256 seconds]
florian_kc has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
Vonter has quit [Ping timeout: 256 seconds]
Vonter has joined #yocto
zpfvo has joined #yocto
lucaceresoli has joined #yocto
olani has quit [Ping timeout: 256 seconds]
pbergin has joined #yocto
GNUmoon has quit [Ping timeout: 276 seconds]
zyga-office has joined #yocto
zyga has quit [Ping timeout: 240 seconds]
mckoan is now known as mckoan|away
<LetoThe2nd>
suppose i have a bsp that provides machineA. now I want to manipulate a couple of things for that machine from my layer, and build for it. am I right in the understanding that MACHINEOVERRIDES does the trick here?
<LetoThe2nd>
e.g. I create a machineA_special, which contains MACHINEOVERRIDES = "machineA:"
<RP>
LetoThe2nd: yes
<RP>
LetoThe2nd: although I'd not put _ in a machine name
<LetoThe2nd>
RP: heh you're right. underscores are one of my bad habits.
<LetoThe2nd>
RP: so then a build for MACHINE = "specialMachineA" gives my machineA + my special sauce - correct?
kroon has quit [Ping timeout: 256 seconds]
Vonter has quit [Read error: Connection reset by peer]
kroon has joined #yocto
<RP>
LetoThe2nd: yes
<LetoThe2nd>
RP: thx
Vonter has joined #yocto
ziga_ has joined #yocto
Vonter has quit [Ping timeout: 256 seconds]
<ziga_>
I have a image that was created with Yocto. I have the password and I can login. How can I check which Yocto project version was used to create the image? I tried using "uname -a" which outputs: "Linux 4.8.3-yocto-standard #1 PREEMPT Tue Feb 19 19:30:06 UTC 2019...".
<LetoThe2nd>
ziga_: /etc/os_release
<ziga_>
This file was removed from the image. It does not exist. Any other method?
<LetoThe2nd>
ziga_: nothing concise that i know of. yocto-standard sounds like at least the kernel is a generic one, so you can go digging which release supported 4.8
<RP>
ziga_: you can compare the versions of things in the image with versions of things in different yocto releases
Vonter has joined #yocto
<qschulz>
LetoThe2nd: don't forget that it's =. and BEFORE any include/require in the configruation file
<LetoThe2nd>
qschulz: thanks, good hint!
<ziga_>
I tried the kernel - I am using Beaglebone Black so I assume that person who created the image used meta-ti layer and kernel linux-ti-staging. But when I search through releases of linux-ti-staging I can't find exact match - it looks like "morty" comes the closest (https://github.com/YoeDistro/meta-ti/tree/morty/recipes-kernel/linux) but that is not it. I need 4.8.3 :/
<LetoThe2nd>
ziga_: then i'd say, get in touch with the one who did the build.
GNUmoon has joined #yocto
<ziga_>
He vanished without a trace and left company (our customer) in pain. :D
davidinux has quit [Ping timeout: 240 seconds]
kroon has quit [Ping timeout: 240 seconds]
rfuentess has joined #yocto
<LetoThe2nd>
ziga_: then you might need to hire some assistance.
<derRichard>
is there a good way to debug sstate-cache cache misses? i'd like to understand why a fully populated sstate-cache (provided via SSTATE_MIRRORS) matches only 40%. some of my recipes/layers must be wonky.
<qschulz>
I think there's seomthing related to hashserv?
<qschulz>
I remember only hitting 55% sstate-cache reuse on dunfell a few months back
olani has joined #yocto
* derRichard
finds oe-check-sstate
<derRichard>
qschulz: so, even with a clean yocto release i won't have a good cache utilization? :-(
<derRichard>
i'm on hardknott bte
<derRichard>
btw
vladest has quit [Remote host closed the connection]
<qschulz>
yeah, I had 55% on vanilla poky
<derRichard>
oh dear.
<qschulz>
there's probably something to do know with the hashserv. I think there's one that's publicly accessible?
<qschulz>
otherwise, you need to host your own
<qschulz>
IIRC, haven't looked at that
<derRichard>
wtf is hashserv? :)
<qschulz>
the counterpart of sstate-cache
<qschulz>
sstate-cache stores what is the hash of a task and its output so that if a task has the same hash, the sstate-cache output can be reused
<derRichard>
as long it is some bitbake internal i'm good. but my build need to work offline.
<qschulz>
however, this is quite inefficient if you change something small in a task, e.g. a space, which does not change the outcome of a task
<derRichard>
in my case it rebuild even core stuff like gcc and glibc ;-\
<derRichard>
if it rebuilds customer applications all time, i'm still fine with it
<qschulz>
which means that bitbake will now detect that both tasks have the same output, therefore the rest of the task dependency tree can be taken from sstate-cache instead of being rebuilt because the new task is slightly changed
<RP>
derRichard: are you sharing an sstate cache without sharing a hash equivalence server ?
<derRichard>
RP: i fear so. so, what is the right way to share sstate cache across multiple users/machines?
<RP>
derRichard: what you're doing is correct however it misses a key detail. We enabled hash equivalence by default in some of our recent releases and this "defeats" sstate sharing :/
<RP>
derRichard: so either disable hash equivalence or share the hash equivalence data with sstate
vladest has joined #yocto
<derRichard>
hm, i need to read on "hash equivalence" first. i have little idea what this is
<RP>
derRichard: it tracks what the output of sstate tasks looks like and if it was the same as a previous build, it marks them as equivalent and skips the following other things that might have rebuilt
<qschulz>
I think michaelo wrote some documentation on this recently?
<RP>
qschulz: I will let you point to that :)
<derRichard>
i thought this is all what sstate cache does? why do i need to disable it to utilize the cache?
<RP>
derRichard: sstate just dumbly caches the output of tasks. It doesn't short circuit later tasks if the output hasn't changed, only if the input is the same
<RP>
derRichard: you'd better look at the manual :/
* derRichard
reads :)
<derRichard>
actually i was just looks for a way how to use sstate-cache better. now i ended up in interals :)
<RP>
derRichard: just disable hash equivlance then
* RP
shurgs. You asked why
<derRichard>
RP: :-)
<derRichard>
ah, since zeus BB_SIGNATURE_HANDLER is set to OEBasicHash
<derRichard>
and when i set it back to OEBasic things should work
<RP>
derRichard: no :/
<derRichard>
not?
<RP>
I said disable hash equivalence, not change the signature handler
<RP>
LetoThe2nd: I'm not sure that is a definitive list now but those things are certainly good
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
<LetoThe2nd>
RP: yeah. I'm just currently preparing something which will actually highlight the benefits of having proper layers, and possibly HW vendors that pörovide such.
sakoman has joined #yocto
<derRichard>
RP: okay. i don't get it. from the docs i understand that BB_SIGNATURE_HANDLER controls the hash equivalence feature. but a few lines before you told me BB_SIGNATURE_HANDLER is something different
<RP>
derRichard: it is controlled by BB_HASHSERVE. Ensure that isn't set
<RP>
derRichard: I think I'm misremembering how this works, sorry :(
florian_kc has quit [Ping timeout: 240 seconds]
<derRichard>
RP: part of my confusion is, when i unset BB_HASHSERVE, i get "ERROR: OEEquivHash requires BB_HASHSERVE to be set". so i need to touch BB_SIGNATURE_HANDLER too
<RP>
derRichard: I thought you could just remove BB_HASHSERVE and disable it but looking at the code I guess not. Sorry, I'm not at my best today :(
<derRichard>
no problem at all. :-)
<kayterina[m]>
where can I see the series of commands that run with bitbake <target>? For example that a task runs before do_compile or if I can see dependencies between them
<qschulz>
kayterina[m]: bitbake -g <target> and then look at one of the dot files (don't use dot)
<derRichard>
just to very sure: when i build a target, save sstate-cache somewhere else on my local disk and later use the very same layers/recipes/local.conf plus SSTATE_MIRRORS set to the previously saved sstate-cache, i should get close to 100% cache utilization, right? (with hashserve being disabled)
<RP>
derRichard: you mentioned OEBasic and I suspect you want the OE core default, OEBasicHash
<kayterina[m]>
aah...that infinite parsing of recipes
<LetoThe2nd>
kayterina[m]: bitbake -g target, then you can look at the task-depends.dot
<LetoThe2nd>
qschulz: hi5
<RP>
derRichard: and yes, you should
<derRichard>
RP: hmm, this is not what i see. maybe there is something else wonky
<derRichard>
and yes, OEBasicHash of course, not OEBasic :)
* derRichard
diggs deeper
<RP>
there is a huge difference between the two
<derRichard>
yes, i figured :)
<kayterina[m]>
then I can ask directly does 'bitbake <target>' executes 'sysroot_populate' and if so, it should equal to devtool build
shoragan has joined #yocto
ykrons has joined #yocto
<RP>
kayterina[m]: bitbake <target> executes the do_build task of target
<RP>
kayterina[m]: anything that is depended upon by the do_build task would run
xmn has joined #yocto
<agherzan>
There seems to be an issue in the GMT time for the weekly triage meeting. It states 14.30GMT and it should be 15.30GMT
<agherzan>
I'm not sure whom to ping for the change
<rburton>
stephen jolley is the owner of the invite
dtometzki has quit [Ping timeout: 256 seconds]
dtometzki has joined #yocto
ar__ has joined #yocto
<RP>
sakoman: can you please trim that crazy size email next time you reply, my email client hates it!
<RP>
agherzan: you definitely need stephen for that
<sakoman>
RP: Sorry! Will do
<RP>
sakoman: a cpu core goes awol for a minute if I scroll past any of that thread :)
<sakoman>
I fear I replied a second time before seeing your message
<agherzan>
@RP thanks
vmeson has joined #yocto
pbergin has quit [Quit: Leaving]
codavi has joined #yocto
davidinux has quit [Ping timeout: 240 seconds]
davidinux has joined #yocto
ar__ has quit [Ping timeout: 256 seconds]
jatedev has joined #yocto
Vonter has quit [Ping timeout: 256 seconds]
Vonter has joined #yocto
kroon has quit [Quit: Leaving]
Minvera has joined #yocto
Tokamak has joined #yocto
olani has quit [Remote host closed the connection]
<rburton>
khem: do you have a new glibc recipe in flight already?
smsm has quit [Ping timeout: 256 seconds]
sstiller has quit [Remote host closed the connection]
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
frieder has quit [Remote host closed the connection]
<rburton>
PSA: the unshare trick done by latest bitbake doesn't work inside non-privileged docker containers
<JPEW>
rburton: Not really that surprising I suppose
<rburton>
it blocks unshare entirely, there's tickets for allowing user namespaces to work but they're untouched for months
zpfvo has quit [Remote host closed the connection]
<shivamurthy>
this is dunfell release
zpfvo has joined #yocto
florian has quit [Quit: Ex-Chat]
zpfvo has quit [Client Quit]
ex-bugsbunny has joined #yocto
<ex-bugsbunny>
hi y'all :-)
<ex-bugsbunny>
I have a question about BBFILES_DYNAMIC
<ex-bugsbunny>
in the past I fiddled with dynamically using BBMASK to avoid .bbappend files in case the base recipe is missing until I read about that fine variable
<agherzan>
RP: Any hints on how to reproduce #14484? I didn't manage on a simple build.
<ex-bugsbunny>
however, I mis-used it first, because I took the "Use the BBFILES_DYNAMIC variable to avoid" in the documentation more serious than the "Activates content" in the very beginning.
<ex-bugsbunny>
my expectation was: yeah, great, just add the paths in question to that variable and leave BBFILES variables untouched, bitbake will sort out the dynamic files from the BBFILES, but obviously I was wrong
<ex-bugsbunny>
so my question: why was it implemented that way?
<ex-bugsbunny>
I mean, it is great to have that dynamic way of handling recipes and append files, but it forces you to restructure the layers once you find something becoming dynamic (because the layer gets re-used in a different context)
<RP>
agherzan: it is a rare race so it probably won't reproduce easily. If you wanted to you'd need to creating something that would brute force it, running many package creations in loops
<RP>
agherzan: I did worry it was some kind of race in psuedo's file deletion paths too :/
<agherzan>
RP: looks like it. Ok. I'll keep messing up with it
ex-bugsbunny has quit [Ping timeout: 256 seconds]
leon-anavi has quit [Ping timeout: 256 seconds]
prabhakarlad has joined #yocto
Vonter has quit [Ping timeout: 256 seconds]
rfuentess has quit [Remote host closed the connection]
Tokamak has quit [Ping timeout: 256 seconds]
florian_kc has joined #yocto
lucaceresoli has joined #yocto
Tokamak has joined #yocto
prabhakarlad has quit [Ping timeout: 256 seconds]
jatedev has quit [Quit: Client closed]
<shivamurthy>
Hi All, I am getting a problem while building dunfell release on Ubuntu 20.04.
<shivamurthy>
rfs613: the problem started after I upgraded (sudo apt update and sudo apt upgrade)
<rfs613>
hmm so maybe a recent ubuntu update, okay
<rfs613>
I guess others will run into this also ;-)
<shivamurthy>
rfs613: around 60 packages upgraded, I am not sure the way to find that list now to downgrade :(
<rfs613>
shivamurthy: agreed. It might be something simple, like the autoconf package needs to list help2man as a new dependency. I'm just guessing here, there are others who are a lot more knowledgeable on the channel.
<vd>
is bmaptool faster than dd even without a .bmap file, or is it the same without it?
<shivamurthy>
rfs613: that not worked for me
jatedev has joined #yocto
<rfs613>
shivamurthy: i'm looking at the list of updates.. the only one that jumps out at me is command-not-found got updated, it seems like a long shot, but maybe that broke something? There don't seem to be any updates to autoconf, help2man, or even very many -dev packages.
<khem>
vd: without mapfile bmaptool is no much different
<vd>
khem: thanks
<khem>
rfs613: does help2man-native appears in the DEPENDS of autoconf recipe
<rfs613>
khem: DEPENDS="m4-native gnu-config-native texinfo-dummy-native" so it looks like no...
<khem>
ok then add it
<rfs613>
shivamurthy: ^^ can you give that a try?
<shivamurthy>
rfs613: DEPENDS="m4-native gnu-config-native texinfo-dummy-native help2man-native" , like this?
<rfs613>
hmm, circular loop of dependencies maybe?
<shivamurthy>
yes
<JPEW>
rburton: Hmm, I wonder if podman works; I had assumed that's what you were using when you said "unprivledged" :)
<rfs613>
ah yes, help2man-native has DEPENDS=" autoconf-native automake-native"
<rfs613>
khem: how to break the loop?
alessioigor has joined #yocto
<khem>
oh
<khem>
I think autoconf should not be using help2man
<khem>
so I wonder why its coming
<khem>
as dependency in your build
alessioigor has quit [Client Quit]
<khem>
can you delete your tmp/ and rebuild
<rfs613>
(and undo the change to DEPENDS of course)
<shivamurthy>
ok
<shivamurthy>
this time I cleaned, tmp, downloads, sstate-cache, and cache
<shivamurthy>
also removed help2man from autoconf.inc
<shivamurthy>
but, instead of bitbake core-image-minimal, I tried bitbake autoconf-native
<rfs613>
ok, it will still likely build a bunch of dependencies first before getting to autconf-native
<shivamurthy>
same problem I am getting, ^^^ rfs613 and khem
<shivamurthy>
rfs613 ^^^
<rfs613>
oh that's fast ;-)
jatedev has quit [Quit: Client closed]
<shivamurthy>
I removed DEPENDS once I got those errors
<shivamurthy>
:)
<rfs613>
i'm trying to get my qemux86_64 build working, so I can test out the same things
jatedev has joined #yocto
<rfs613>
ok, I am seeing help2man: command not found.... but this is ignored and the build continues anyway
<rfs613>
shivamurthy: so I'd suggest we look at your original error log more carefully, maybe there's something besides the help2man going wrong? (eg. earlier than what you posted in 3WRitbNG)
<jatedev>
Is github changing default branch names from master to main? People are starting to do this and it's affecting my builds
<rfs613>
jatedev: for new repos yes... and some projects are changing their existing master branch
<akiCA>
Hello folks, anyone familiar with meta-java online? It fails to parse with error: meta-java/recipes-core/icedtea/icedtea7-native_2.1.3.bb: QA Issue: recipe uses DEPENDS_${PN}, should use DEPENDS [pkgvarcheck]
<shivamurthy>
rfs613: ok, does system upgrade cause this problem?
<akiCA>
But I don't see DEPENDS_${PN} being used anywhere in recipe or included files
<rfs613>
shivamurthy: I'm hesitant to try that right now, as I don't want to break my builds right now.
<shivamurthy>
rfs613: I understand :)
<rfs613>
shivamurthy: i'd need to setup the same thing inside a vm or docker, so I can upgrade without affecting my real build.
<rfs613>
but i have to go pickup kids from school in 10 mins, so no time for that now
<shivamurthy>
rfs613: i have old lxc container snapshot, let me try
<khem>
shivamurthy: I think you need to find why help2man is being needed for autoconf-native
<khem>
thats the root issue, it should not be needed
<rfs613>
khem: if you look at both shivamurthy and my logs (on pastebin) they both clearly try to call help2man... as part of "Makeing all in man" from autoconf make
<rfs613>
maybe there is a way to tell autoconf not to recurse into the 'man' directory... or we could patch that out.
<RP>
smurray: we're at the "see what breaks" stage of testing so if there is a huge issue, now is the time to flag it!
<smurray>
RP: okay, I'll rig up a test tree here. I suspect our issues will be more with agl-compositor than with the weston bbappend
<RP>
smurray: I figured you may be more sensitive to this one than many
<smurray>
RP: heh, it's several of the vendor BSPs that are likely borked for a while, but I've only been testing AGL's "next" branch with qemu & rpi4 for the most part
<smurray>
RP: the other fun things for BSPs will be gstreamer & mesa 22 if they make it into kirkstone
<RP>
gstreamer has patches so that is possible. I've not seen mesa yet
<kanavin>
mesa updates are usually straightforward, so I think it's likely to make it too
<kanavin>
khem, I have llvm 13.0.1 upgrade patch lined up