<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>
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.
<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 :(
<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]