goliath has quit [Quit: SIGSEGV]
khem has joined #yocto
<khem> hello all
sakoman has quit [Quit: Client closed]
tgoodwin has joined #yocto
tgoodwin has quit [Quit: Textual IRC Client: www.textualapp.com]
onoffon has joined #yocto
onoffon has quit [Client Quit]
onoffon has joined #yocto
nerdboy has joined #yocto
khem has quit [Quit: Client closed]
onoffon has quit [Quit: Sleeping]
khem has joined #yocto
khem has quit [Quit: CU]
khem has joined #yocto
khem has quit [Client Quit]
khem has joined #yocto
paulg has quit [Ping timeout: 264 seconds]
rcw has quit [Ping timeout: 264 seconds]
tgamblin has quit [Ping timeout: 252 seconds]
<armpit> hello
Spooster has quit [Remote host closed the connection]
elfenix has quit [Ping timeout: 264 seconds]
halstead has joined #yocto
<khem> armpit crickets here
zyga has quit [Quit: Textual IRC Client: www.textualapp.com]
zyga-mbp has joined #yocto
gsalazar has joined #yocto
<perdmann> Is there a way to stabilize dbus? I use sdbus and i randomly get Connection Timed Out. Is there a (standard?) way to stabilize this?
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zyga-mbp has joined #yocto
<ndec> hey RP , how did you build x86_64-buildtools-docs-nativesdk-standalone-3.2+snapshot-20201105.sh that we use in run-docs-build? perhaps we should make proper releases for that. I've realized that my own local sphinx was outdated here.. that made me think we should worry about the one we officially use ;)
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<qschulz> ndec: At one point, I think it'll make sense to hardcode the version used for Sphinx to build the doc? https://git.yoctoproject.org/cgit.cgi/yocto-docs/tree/documentation/Pipfile should be the place to add this IIUC
<qschulz> we can obviously change/update/extend this version support later on but at least it'd show with what we're testing compilation and what we use to build it?
<ndec> yes, probably. but we don't use Pipfile in the AB where we build the official doc we publish..
<ndec> we can do version check in conf.py directly, to ensure that everyone uses what *we* chose.
<qschulz> ndec: wouldn't have detected our issue since what we're using is working and newer releases aren't :)
<qschulz> I used 3.4.3 or 3.4.1 I think
<ndec> i know.. the code above is what we have today in conf.py
<qschulz> ndec: ah! I thought you were suggesting something new :) indeed it's in conf.py already
<qschulz> ndec: I wanted to enable https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-nitpicky too but cannot make sense of what this is supposed to do
<ndec> qschulz: i looked at nitpick option a while ago and didn't get anything as well..
zyga-mbp has joined #yocto
tnovotny has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tgamblin has joined #yocto
tnovotny has quit [Read error: Connection reset by peer]
prabhakarlad has joined #yocto
tgamblin has quit [Quit: Leaving]
paulg has joined #yocto
tgamblin has joined #yocto
iokill has joined #yocto
sakoman has joined #yocto
tgamblin has quit [Quit: Leaving]
tgamblin has joined #yocto
* armpit feels like jet lag do to the summit and i didn't even fly
khem40 has joined #yocto
khem40 is now known as onoffon
onoffon has quit [Client Quit]
<qschulz> armpit: true dedication
vmeson has joined #yocto
zyga-mbp has joined #yocto
zyga-mbp has quit [Ping timeout: 248 seconds]
zyga-mbp has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zyga-mbp has joined #yocto
prabhakarlad has quit [Quit: Client closed]
<khem> armpit I use to feel flying after few drinks no matter where I was
gsalazar has quit [Ping timeout: 264 seconds]
ingonus has joined #yocto
<ingonus> HI, i'm trying to enable psplash on my image, but when it boots, it shows the error can't find /dev/fb0. Anyone knows how to fix it?
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<khem> it means you dont have framebuffer support enabled in system perhaps in kernel
<ingonus> humm... thank you
<ingonus> it can be enable by menuconfig?
<ingonus> I saw in a forum that I have to enable distro feature directfb
<ingonus> I tried this, but didn't work
<ingonus> In my defconfig I have this options
<ingonus> CONFIG_FRAMEBUFFER_CONSOLE=y
<ingonus> CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
<ingonus> # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
<ingonus> # CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER is not set
<NishanthMenon> I have found many DRM based systems need CONFIG_DRM_FBDEV_EMULATION
<ingonus> humm, mine is disabled
<ingonus> I will try that
<ingonus> thank you sir
<ingonus> do I need to set DISTRO_FEATURE_append = "directfb" ?
bluelightning has joined #yocto
lexano has joined #yocto
<RP> ndec: that was done with some branch which had the doc tools in. I'd have to try and remember where it went. The assumption was we'd sort this out somewhere and then I've promptly forgotten :(
zyga-mbp has joined #yocto
zyga-mbp has quit [Quit: Textual IRC Client: www.textualapp.com]
<smurray> RP: is the multiconfig change you were looking to have tested this one: "bitbake: runqueue: Improve multiconfig deferred task issues"?
<fray> smurray there is one more beyond that AFAIK..
<fray> it fixes a 4-way built, but I'm still getting issues
<fray> (just a lot less)
<smurray> I'm seeing an issue testing something where it almost looks like it could related
<fray> the issues I see are deferred tasks deadlocked, so the system falls back to picking one and running it..
<fray> without those patches additionally it may run the same task in different iterations and you'll get errors in setscene about how the sstate-cache file was missing
<smurray> with this setup I'm trying atm the TMPDIR is shared, and with rm_work enabled I see a reproducible issue where the multiconfig toolchain build seems to try to build bc-native again (and fails) after the main build has done it and rm_work has cleaned it out
<smurray> bit of an odd setup, maybe, but the steps to where I'm at were all reasonable ;)
<smurray> if I disable rm_work, it looks like it fixes it, need to try a couple more times to be sure
<smurray> I'll probably hack in using a separate TMPDIR as a separate test
<fray> in mye xpereince you can't share a tmpdir with multiconfig.. it simply doesn'ts work
<fray> I hit issues with rm_work, but I also hit issues with image generation..
<fray> also I have to set a different path for buildhistory or that will also deadlock occasionally..
<fray> (build history uses the same filename.. so it overwrites or can get deleted out from under it)
rcw has joined #yocto
jordemort has joined #yocto
<smurray> fray: interesting re buildhistory, I'd not thought of that
<smurray> fray: given the high likelihood of failure, I wonder if just making bitbake default to separate TMPDIRs with multiconfig might be the way to go
<smurray> fray: though the bikeshedding potential on what the naming/structure should be seems high ;)
<fray> ya I set my TMPDIR with the MC in my local.conf
<fray> existing structure .= the mc name.. default remains the same.. mc's get appended no overlap
<fray> (I'm forgetting the variable, but there is one that is easy to add)
<RP> smurray: I'm probably not in a fit state to talk coherently about multiconfig atm :)
<smurray> RP: heh, no worries
<RP> smurray: " runqueue: Improve multiconfig deferred task issues" is the patch which needs testing and known to cause some issues we haven't been able to trace
<RP> it does need the fixup after it
<RP> You should be able to share a tmpdir if it is only machines changing between the different configs
<smurray> RP: heh, "should"
<smurray> RP: I'll try rigging up a test with those changes on the weekend
<JPEW> fray: Ya, we do some stuff to make buildhistory work with multiconfig
<JPEW> Bascially, before the CI build runs, we clone down our buildhistory multiple times (once for each MC we know we are building), each checkout out on a branch named after the mc, then we do BUILDHISTORY_DIR = "${TOPDIR}/buildhistory/${BB_CURRENT_MC}"
<JPEW> And manually push them back when the build is done
<fray> ya that's the variable.. TMPDIR .= "-${BB_CURRENT_MC}" is what I added ot each of my multiconfigs as well
<JPEW> fray: Ya, that works. I usually set them more explicitly like TMPDIR = "${TOPDIR}/tmp-${BB_CURRENT_MC}" because you have to know where they are for mcdepends to work
<JPEW> The .= would be hard if you wanted a non-default (base) multiconfig to pull items from another
<fray> yes.. for the builds I'm doing I don't need that.. but some of my reference multiconfigs do exactly that.. set the TMPDIR to a known location so I can pickup and package the output of a different multiconfig
ingonus has quit [Quit: Client closed]
<dl9pf> and if you both do that ... shouldn't it be the default then ?
<dl9pf> same with buildhistory ... users won't know until they get bitten
jordemort has quit [Quit: node-irc says goodbye]
rcw has quit [Quit: Leaving]
mattsm has joined #yocto
mattsm has quit [Read error: Connection reset by peer]
mattsm has joined #yocto