invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #yocto
gho has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Herrie|Laptop has quit [Remote host closed the connection]
mckoan|away is now known as mckoan
<mckoan>
good morning
barometz has quit [Quit: you can't fire me!]
barometz has joined #yocto
prabhakarlad has joined #yocto
<LetoThe2nd>
yo dudX
<mcfrisk>
morning! I'm choking on coffee after figuring out that all oeqa runtime tests are setting timeouts wrong... !"#¤ python
florian_kc has joined #yocto
apteryx has quit [Ping timeout: 268 seconds]
xmn has quit [Quit: ZZZzzz…]
ptsneves has joined #yocto
apteryx has joined #yocto
paulg has quit [Ping timeout: 260 seconds]
bps2 has joined #yocto
xmn has joined #yocto
xmn_ has joined #yocto
xmn has quit [Ping timeout: 246 seconds]
tnovotny has joined #yocto
paulg has joined #yocto
<RP>
mcfrisk: morning! the oeqa code could use some cleanup and attention :/
<RP>
it keeps the project alive but...
<landgraf>
people just addings stuff there. iirc there're few almost identical wrappers around git here and there
thomasd13 has quit [Ping timeout: 246 seconds]
<landgraf>
bisecting why systemd+musl+usrmerge is broken in kirkstone is funny...
bps2 has quit [Ping timeout: 252 seconds]
xmn_ has quit [Ping timeout: 264 seconds]
seninha has joined #yocto
seninha has quit [Remote host closed the connection]
seninha has joined #yocto
Guest2941 has joined #yocto
<mcfrisk>
RP: could I set a default timeout of say 60 seconds to all oeqa runtime target.run() calls? targets and commands can hang for ever and no-one wants that. fully hanging qemu will result in process leakage too when the qemu-system process is killed, cooker and worker processes are left dangling..
<rburton>
sounds sensible
<rburton>
i remember removing a load of code which was randomly setting 600s timeouts for no good reason
<RP>
mcfrisk: I suspect there are things which run for a lot longer than 60s (ptests, ltp and so on)
<mcfrisk>
yea, now all tests set the value run(.., 1500) but should be setting run(.., timeout=1500), and that's what I copied to our tests and then when qemu hangs...
<mcfrisk>
RP: ok, I don't mind a 600 second default timeout either, but no timeout and no upper limit is bad
<rburton>
i keep on threatening to rewrite oeqa from scratch
<landgraf>
mcfrisk: I recall increasing timeout inside of rpm runtime test from 30 to 120 seconds few weeks ago as a workaround for systemd bug. setting 60 for entire test may break it (and probably there're mot cases like this)
<RP>
mcfrisk: I'm happy to have a high timeout, I just know some things will struggle with 60s
<RP>
mcfrisk: We should try and fix that process leakage too btw :/
<RP>
rburton: please don't, I don't think I could take all the new bugs
<mcfrisk>
yea, I can imagine the breakage.. so a really high value will be ok. But I had 17 hour test runs for trivial tests where qemu hangs..
<mcfrisk>
oeqa runtime tests will improve if there are more users for them, and some adaptations are easy to do on custom layers
<mcfrisk>
it's better than everyone using their own custom test frameworks
<Qorin>
Hi everyone, is anyone familiar with how efivar variable get loaded?
<Qorin>
I have 2 devives with me, dev A (Intel Atom Processor E3940) and dev B(Intel Atom x6425RE). Both HWs have different BIOS.
<Qorin>
I am building an image using honister build. with A, there is no issue. however with B, when i listed the variables (with evivars -l, efibootmgr -v or checking /sys/firmware/efi/efivars), B is missing BootCurrent, but other variables are there for e.g BootOrder or Boot00XX.
<Qorin>
Does anyone know where can I go from here.
camus1 has joined #yocto
camus has quit [Remote host closed the connection]
camus1 is now known as camus
bps2 has joined #yocto
azcraft has joined #yocto
azcraft has quit [Remote host closed the connection]
<LetoThe2nd>
hsv: and keeping your source in there, effectively mangling the package build process into the recipe is a bad idea in any case.
<hsv>
Maintaining the same file list in both the Makefile and bb file seems wrong.
<hsv>
LetoThe2nd: what should i read to get this right?
<rburton>
hsv: maintain the source code outside the layer, like in another git repo. the yocto layer should just be the recipes: fetch code from here, run make.
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #yocto
<hsv>
I see, so the edit/build/test workflow should involve a git commit each time?
<rburton>
if you're actively iterating on code then look up the externalsrc code
<rburton>
class, even
<hsv>
thanks i will try it.
Guest2941 has quit [Quit: Connection closed]
alessioigor has quit [Quit: alessioigor]
Guest79 has joined #yocto
alessioigor has joined #yocto
Guest79 has quit [Client Quit]
erik__ has joined #yocto
Tyaku_ has quit [Quit: Lost terminal]
Tyaku has joined #yocto
<ptsneves>
Hey people, is there any manual about tinfoil? Is it an official API?
sakoman has joined #yocto
xmn has joined #yocto
<dacav>
Hello. Is there a way to extend the license.manifest file with additional info? E.g. the content of SRC_URI
JaMa has quit [Quit: reboot]
JaMa has joined #yocto
manuel1985 has joined #yocto
<rburton>
ptsneves: official yes. docs, not really. plenty of examples in scripts/ though, including some really basic ones
<RP>
ptsneves: it is official and there are tests too
<ptsneves>
Thanks! I have been using it but discovered it by mistake. It has been really useful. If documentation would be submitted to what section would it be added?
<RP>
ptsneves: probably a new section in the bitbake manual?
<qschulz>
If I may, mention of tinfoil, a general overview or some features would be good in the docs. But beware of documenting the code or API use in the sphinx docs.. I don't think it's a good idea (I think it'd be best to have python code documented in-line/in the code directly)
<qschulz>
I think we had the same problem with documentation of bb funtions (e.g. bb.util.contains)
<qschulz>
ideally, we should generate sphinx documentation out of python code documentation so that they are kept in sync and encourages documentation in code
<qschulz>
we just don't have the plumbing in the documentation and I expect I'll not have the time to look at this for a long time
<ptsneves>
@qschulz fair enough. Mentioning it would at least assure developers it is public API. I will try to request time to my project so i can submit the overview part at least.
<ptsneves>
@RP why do we have a tinfoil.prepare step separated from the __init__? This means that using the "with bb.tinfoid as t" will fail if we go out before calling tinfoil.prepare.
<RP>
ptsneves: I suspect one doesn't initiate the actual connection, the other does
kscherer has joined #yocto
<ptsneves>
what functionality is targeted by having tinfoil without a connection? I was thinking that with the __init__ calling prepare tinfoil would behave in a RAII'ish way.
<RP>
ptsneves: most code likes to have control over exactly when the connection is initiated and I guess this was to allow more control/configuration over the way the server was setup
<RP>
ptsneves: for reference I didn't write tinfoil so I don't know all the design reasons
<ptsneves>
Sounds reasonable. Thanks.
<RP>
ptsneves: it is clear in the code that it expects you to call prepare()
<ptsneves>
indeed but unusual from a pythonic point of view, i think.
<RP>
ptsneves: bitbake isn't especially pythonic :)
azcraft has quit [Read error: Connection reset by peer]
<ptsneves>
eheh, indeed, but without the documentation this means that one really needs to look at the code. Not a big deal, but brings back the question I made about the existence of any manual about it.
azcraft has joined #yocto
whuang0389 has joined #yocto
manuel1985 has quit [Ping timeout: 255 seconds]
otavio has quit [Read error: Connection reset by peer]
otavio has joined #yocto
manuel1985 has joined #yocto
jmiehe has joined #yocto
<whuang0389>
Why do I keep getting this note:
<whuang0389>
NOTE: Multiple providers are available for runtime coreutils (coreutils, busybox) Consider defining a PREFERRED_RPROVIDER entry to match coreutils.
<whuang0389>
Even though I have it defined in my image recipe: PREFERRED_RPROVIDER:coreutils
<JaMa>
REFERRED_RPROVIDER_coreutils
<JaMa>
P+
<JaMa>
not every _ is a override separator
olani- has quit [Remote host closed the connection]
florian_kc has joined #yocto
louson has joined #yocto
olani- has joined #yocto
<whuang0389>
I've tried the _ as well and still getting the same note
<JaMa>
whuang0389: where did you add this line?
<JaMa>
ah image recipe? you need to add it in global scope (e.g. DISTRO config)
chap has quit [Quit: I laugh with many, but don't trust any.]
Estrella has quit [Ping timeout: 272 seconds]
Estrella__ has quit [Ping timeout: 272 seconds]
Estrella has joined #yocto
yssh has joined #yocto
Estrella_ has joined #yocto
<yssh>
I was building poky image example as per yocto docs, And during the build I got this error:
<yssh>
`ERROR: Failed to spawn fakeroot worker to run /home/bullbust/Work/OSP/Yocto/poky/meta/recipes-sato/images/core-image-sato.bb:do_rootfs: [Errno 32] Broken pipe`
<yssh>
Can anyone tell me what does that mean?
<abelloni>
my guess is that you got an OOM
Estrella__ has joined #yocto
Estrella_ has quit [Ping timeout: 260 seconds]
Estrella has quit [Ping timeout: 264 seconds]
Estrella_ has joined #yocto
olani- has joined #yocto
<yssh>
abelloni OOM has something to do with memory right? Are you saying I am running out of memory?
<abelloni>
yes, you can check your dmesg
<yssh>
abelloni Can you please tell what exactly I should be locking for in dmesg?
<abelloni>
oom or OOM
<yssh>
Ohh I got something named OOM :
<yssh>
`[40900.364474] OOM killer enabled.`
<yssh>
`[40900.364487] Restarting tasks ...`
<yssh>
What should I do Now?
<yssh>
Actually there are lots of messages in dmesg named : `OOM killer disabled.` , `OOM killer enabled`
Vonter has quit [Ping timeout: 268 seconds]
<vmeson>
yssh: add swap file/partiion, buy more RAM, reduce the number of task/jobs (BB_NUMBER_TASKS / PARALLEL_MAke ) or try pressure regulation BB_PRESSURE . Links coming for some of that if you can't find them in docs.yoctoproject.org
<vmeson>
yssh: how much RAM do you have an what are you building?
<yssh>
Learning how yocto works, Trying to build my first poky image
<abelloni>
4G is probably not enough
<abelloni>
I have a customer that struggled with 6GB and an 8GB swapfile
<yssh>
Can it work using 4gb + more swap?
<vmeson>
abelloni: yssh I build poky on my 4 GB RPi4 just to torrment it! I did have to add a large swap file.
<abelloni>
is it building rust ? :)
<vmeson>
yssh: it's ridicously slow but it can be done. You really should get more RAM but if you're trying to learn Yocto and don't have a decent build machine, try core-image-minimal rather than -sato.
<vmeson>
abelloni: lol! that and webkitgtk - I throw: bitbake -k world at it.
<yssh>
vmeson How much swap file I need to create?
<vmeson>
yssh: it's depends what you build but I have an SSD with 32 GB swap and I think ~ 12 GB is used at peak. If you have the space, use at least 16 GB and be prepared to wait.
<yssh>
Ok, Thanks for your reply.
<vmeson>
yssh: good luck and welcome to Yocto!
<yssh>
vmeson Thank you, My pleasure.
mvlad has quit [Remote host closed the connection]
yssh has quit [Quit: Client closed]
seninha has quit [Quit: Leaving]
kscherer has quit [Quit: Konversation terminated!]
seninha has joined #yocto
manuel1985 has joined #yocto
invalidopcode has quit [Remote host closed the connection]