tgamblin has quit [Remote host closed the connection]
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
Tokamak has joined #yocto
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
roussinm has quit [Quit: WeeChat 3.3-dev]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
sakoman has quit [Quit: Leaving.]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
jwillikers has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
xmn has quit [Ping timeout: 265 seconds]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
wbw_ has quit [Remote host closed the connection]
jmiehe has quit [Ping timeout: 240 seconds]
jmiehe1 has joined #yocto
jmiehe1 is now known as jmiehe
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
rfs613 has joined #yocto
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
Lihis has joined #yocto
tgamblin has quit [Remote host closed the connection]
Lihis has quit [Client Quit]
Lihis has joined #yocto
opello has joined #yocto
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
pgowda_ has joined #yocto
Ad0 has joined #yocto
Schlumpf has joined #yocto
adrian_ has quit [Remote host closed the connection]
manuel1985 has quit [Ping timeout: 245 seconds]
alessioigor has joined #yocto
rob_w has joined #yocto
rob_w has quit [Client Quit]
rob_w has joined #yocto
<rob_w>
i am on thud and i am stuck in a loop , wanting to use cryptodev-linux enable, building openssl it misses cryptodev.h then buidling cryptodev-linux it start building opensssl again
tre has joined #yocto
frieder has joined #yocto
alessioigor has quit [Quit: alessioigor]
<JosefHolzmayrThe>
yo dudX
rfuentess has joined #yocto
chrfle has joined #yocto
gsalazar_ has joined #yocto
kpo has quit [Read error: Connection reset by peer]
leon-anavi has joined #yocto
kpo has joined #yocto
<JosefHolzmayrThe>
should it be possible to remove the serial arguments to qemu via the qemuboot.conf? if i set qb_serial_opt = none or an empty string, then i still seem to get the defaults.
tnovotny has joined #yocto
manuel1985 has joined #yocto
vd has quit [Ping timeout: 256 seconds]
vd has joined #yocto
mckoan|away is now known as mckoan
fbre has joined #yocto
<fbre>
Hi! a systemtap script here outputs this message: "Ensure kernel development headers & makefiles are installed". Which yocto package could that be?
<JosefHolzmayrThe>
fbre: if i had to guess, kernel-devsrc
<fbre>
Thanx. Is this something I have to add to IMAGE_INSTALL_append or EXTRA_IMAGE_FEATURES or DISTRO_FEATURES?
<qschulz>
fbre: most packages are installed via IMAGE_INSTALL (if they are not brought into the system by DEPENDS or RDEPENDS of packages that are installed via IMAGE_INSTALL)
<fbre>
(y)
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
zyga-mbp has joined #yocto
florian has joined #yocto
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
mvlad has joined #yocto
amitk has joined #yocto
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
amitk has quit [Quit: leaving]
amitk has joined #yocto
tgamblin has joined #yocto
<manuel1985>
Has anyone an idea why `oe-pkgdata-util list-pkgs` would not mention a package which I have a recipe for? The metalayers IS in bblayers.conf.
<JosefHolzmayrThe>
manuel1985: has the package been built?
tgamblin has quit [Remote host closed the connection]
<manuel1985>
JosefHolzmayrThe: Nope
<manuel1985>
Assumed `oe-pkgdata-util list-pkgs` would list all packages bitbake has access to?
<JosefHolzmayrThe>
manuel1985: see, thats why. it looks at package data. no package data built, nothing to look at.
<manuel1985>
Hm
florian has quit [Ping timeout: 252 seconds]
<manuel1985>
Got it, thanks. Is there a command which just lists all available recipes?
<JosefHolzmayrThe>
bitbake-layers IIRC
<JosefHolzmayrThe>
i mean, oe-pkgdata-util even has in its name that it looks at the packages' data, and not at recipes... ;-)
<qschulz>
bitbake-layers show-recipes IIRC
<qschulz>
or the layer index at layer.openembedded.org
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
florian has joined #yocto
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
davidinux has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
xmn has joined #yocto
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tnovotny has quit [Read error: Connection reset by peer]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
Vonter has joined #yocto
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tnovotny has joined #yocto
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
<mcfrisk>
sigh, new override syntax. this is going to hurt a lot to fix everywhere.
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
<RP>
mcfrisk: :(
<mcfrisk>
I have not seen problems with the old one but I trust you they exist. it's just the manual job of changing it everywhere..
<RP>
mcfrisk: it is less about problems and more that we're pinned into a corner with the older syntax form. There is just no way to move the syntax forward. This gives us options again
tgamblin has joined #yocto
<RP>
mcfrisk: hopefully with the compatibility in older bitbakes it gives you a window to transition things
<mcfrisk>
RP: yea, the new syntax support in dunfell will help, but I will need to resolve this in 10's of BSP and other layers, hopefully not 100's..
tgamblin has quit [Remote host closed the connection]
<RP>
mcfrisk: right, I appreciate it is a pain. We've been avoiding doing anything about the issue for a long time
<mcfrisk>
when I do yocto updates, I don't update the BSP layers, except for minimal changes. override syntax is now one of the needed changes which makes this quite intrusive
<JosefHolzmayrThe>
manuel1985: again, is the package built already, for the current target?
<mcfrisk>
doing the conversion? I find it quite tedious in various BSP layers. Not easy to know when there is a SoC/BSP/machine specific override and when it's variable name postfix
<RP>
mcfrisk: the recent manuals should be on docs.yoctoproject.org, not the www. address
<RP>
mcfrisk: if you know all the machines you build you could pull out the MACHINEOVERRIDES values
gourve_l has quit [Ping timeout: 252 seconds]
otavio has joined #yocto
gourve_l has joined #yocto
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
<mcfrisk>
RP: did you script out the transition or do it manually? if MACHINEOVERRIDES is known, then scripting could be possible.
xmn has quit [Ping timeout: 268 seconds]
<RP>
mcfrisk: I did have a script and put it into the tree iirc. It needed fixups but did a bulk of the work
<JosefHolzmayrThe>
so after some digging, i can say that a simple "runqemu slirp" on any meta-zephyr qemu target doesn't yield any output because something is wrong with the serial port arguments of qemu. if i tinker runqemu to not any explicit arguments, then it works as expected. any pointers on how to proceed now?
tgamblin has joined #yocto
<kanavin>
rburton, unsurprisingly I couldn't find any interesting gtk4 consumers in oe-core. webkit's support is still in development and off by default, vte is only a widget and not an app.
<kanavin>
(and webkit is effectively a widget too)
artri has joined #yocto
rzr has joined #yocto
artri has quit [Ping timeout: 252 seconds]
<wyre>
hi guys, what do you recommend me for cross compilation? I mean, I need to compile my c code and test it in the imx6 module, but have I to generate a new image for every test?
<wyre>
I guess I should be able to compile the code in my desktop PC, after copy the binary in the module through ssh and test it
<wyre>
when tests are successful I of course write a recipe
<wyre>
but ... until then I have to compile the code in here, right?
<manuel1985>
wyre: Don't think you need to create a image for every updated package. Just build your c code using the SDK and copy the binaries onto the machine. Voila, should work.
<manuel1985>
SDK = the toolchain yocto itself uses to build stuff for your target
<manuel1985>
you can also export it and use it standalone
<manuel1985>
it comes as a huge selfextracting shellscript IIRC
<manuel1985>
you install it, and when you want to use it you source some setup-shellscript which sets your environment variables ($CC and others) accordingly
<manuel1985>
when you build your project using autotools our cmake, these envvars will be obeyed, so {autotools,cmake} uses the SDKs toolchain instead whatever is installed on your distro
<wyre>
manuel1985, but what will do `bitbake -c do_populate_sdk <image>`?
<qschulz>
otherwise, start with a recipe for your software, then devtool modify <recipe>, devtool build, devtool deploy-target
<manuel1985>
wyre: It will create the huge selfextracting shellscript I mentioned
<qschulz>
you could probably run devtool add <git repo/tarball>
<qschulz>
to bootstrap your recipe
fbre has quit [Quit: fbre]
<JosefHolzmayrThe>
how are the qemuboot conf files supposed to work? shouldn't they basically set up everything once runqemu is being kicked off?
amitk has quit [Quit: leaving]
amitk has joined #yocto
vd has quit [Quit: Client closed]
vd has joined #yocto
<JaMa>
RP: there seems to be another race issue when cleaning sysroot, today I've seen autoconf-native failing due to gnu-config-native missing in recipe-sysroot-native and log.do_patch shows: NOTE: autoconf-native/2.71-r0/recipe-sysroot-native/installeddeps/gnu-config-native.complete no longer exists, removing from sysroot
<zeddii>
I just saw the same thing
<zeddii>
I did a cleanall on autoconf and restarted and it proceeded
<JaMa>
yes, cleanssstate or clean is enough to "fix" this
<RP>
JaMa: hmm, I saw that too. I thought it was just my local mess :/
<JaMa>
It wasn't just gnu-config-native, texinfo-dummy-native, m4-native as well, possibly due to quilt-native signature change https://dpaste.com//8LZZX5YYF
<RP>
zeddii: I've sent a revised reproducibility patch from the kernel perspective, we can try and keep paulg happy or happier :)
<RP>
paulg: having this configurable separate from reproducible builds makes more sense
artri has joined #yocto
<paulg>
funny, cause I was just re-living the trauma of that stupid cgroup/dentry bug while talking with zeddii on what branches we can nuke as EOL.
<paulg>
v5.10/standard/base-noaufs and friends.
<qschulz>
RP: first != is wrong, it should be 0 and not 1 for KERNEL_DEBUG_TIMESTAMPS
<paulg>
poor slandered aufs....
<RP>
paulg: sounds like a traumatic day!
<RP>
qschulz: well spotted, I'lfix that thanks
* RP
is failing at multitasking :/
<RP>
qschulz: it is the second which is wrong :)
<qschulz>
mmmm wait, or is the second one the one that is incorrect?
<qschulz>
eheh :)
<qschulz>
was checking
<qschulz>
seems like I too am failing at multitasking :)
<RP>
paulg: aufs did seem like a likely suspect at the time but I do apologise and agree it was not to blame! :)
sakoman has joined #yocto
<paulg>
that was one crazy bug to squash.
<RP>
paulg: thankfully we don't get those every day. The autobuilder has been a lot calmer without a few of these!
atril has joined #yocto
camus has joined #yocto
<paulg>
oooh - working "cat /proc/version" again. That will be nice.
<paulg>
thanks
Pan5ky has joined #yocto
artri has quit [Ping timeout: 265 seconds]
scjg has left #yocto [#yocto]
tre has quit [Remote host closed the connection]
camus1 has joined #yocto
camus has quit [Ping timeout: 245 seconds]
camus1 is now known as camus
kiran_ has joined #yocto
vd has quit [Quit: Client closed]
vd has joined #yocto
Vonter has quit [Ping timeout: 245 seconds]
<jonmason>
zeddii: beaglebone-yocto and genericx86/86-64 should work with runqemu, right?
<zeddii>
in theory! :D
<jonmason>
ok, then my patches are valid
<jonmason>
it does make it weird that edgerouter is the only one without qemu stuff then
roussinm has joined #yocto
<zeddii>
Just in my painful experience, you eventually run into a confict between the h/w and the emulated h/w .. in that they need different configs.
<zeddii>
which is why I carve out the qemu* machines, so we can apologetically make them targetted to qemu :D
<jonmason>
the qemu stuff was just a little wrong and incomplete, which makes me think that no one is testing it this way
<zeddii>
that doesn't make patches for the other case invalid, just that we can eventually just stop when that conflict pops up.
<zeddii>
and at the time, mainline qemu wouldn't boot the beagle image. I haven't checked for years now.
florian_kc has joined #yocto
<jonmason>
shouldn't WR have a beagle in their test farm and use this image?
<jonmason>
can we poke that bear?
<rburton>
yes, they should
Pan5ky has quit [Ping timeout: 264 seconds]
Guest52 has joined #yocto
Guest52 is now known as Pan5ky
wyre has joined #yocto
Schlumpf has quit [Quit: Client closed]
kpo has quit [Read error: Connection reset by peer]
kpo has joined #yocto
<kergoth>
Has anyone ever seen sysroot_stage_all hang? Specifically the find | cpio is hung up for hours on a trivial amount of files in the imx-boot recipe, ubuntu 18/20 hosts, runs fine outside of the bitbake build
Vonter has joined #yocto
<RP>
kergoth: seems strange. Any circular symlinks or anything like that?
<RP>
kergoth: I use ubuntu 20 and haven;t seen it
<kergoth>
very strange. don't think so, but i'll check
<kergoth>
oh, and dunfell
<RP>
kergoth: it is possible it was using coreutils-native instead which could be a difference
<smurray>
RP: nope, just say the word. BUILD_REPRODUCIBLE_BINARIES goes away as well if iiuc?
<RP>
smurray: correct. I'll test the series and let you know. This was just a heads up it is coming :)
bps has quit [Ping timeout: 252 seconds]
<RP>
I could have left an empty class but it is an obvious error
rob_w has quit [Quit: Leaving]
rfuentess has quit [Remote host closed the connection]
<tnovotny>
Hi, I'd like to know which task is copying files from $IMGDEPLOYDIR to $DEPLOY_DIR_IMAGE. The files are copied after do_image_complete, but this task executes just image postprocess commands (and there is only buildhistory stuff).
<RP>
tnovotny: it will be the sstate postfunc to that task
<tnovotny>
RP: ok. I tried --no-setscene and --skip-setscene to check it but it failed somehow. I will dig further that way. Thank you.
<RP>
tnovotny: images are unusual in that we never generate the sstate artefacts so there never would be an setscene task for them but they still use the sstate code as it allows cleanup of the task to rerun it
dev1990 has joined #yocto
Tokamak has joined #yocto
michaelo[m] has quit [Quit: You have been kicked for being idle]
<tnovotny>
RP: ahaaa, so the sstate code and 'sstate-inputdirs' and 'state-outputdirs' perform the copy?
<RP>
tnovotny: yes
<tnovotny>
RP: great, thank you a lot
camus has quit [Ping timeout: 252 seconds]
camus has joined #yocto
<RP>
kanavin: in that ab-helper change, will it handle the symlinks ok?
<RP>
kanavin: I didn't try but I think it may need to be cp -L?
jordemort has quit [Quit: Bridge terminating on SIGTERM]
shoragan[m] has quit [Quit: Bridge terminating on SIGTERM]
Barry[m] has quit [Quit: Bridge terminating on SIGTERM]
t_unix[m] has quit [Quit: Bridge terminating on SIGTERM]
jmlemetayer[m] has quit [Quit: Bridge terminating on SIGTERM]
kayterina[m] has quit [Quit: Bridge terminating on SIGTERM]
ericson2314 has quit [Quit: Bridge terminating on SIGTERM]
Emantor[m] has quit [Quit: Bridge terminating on SIGTERM]
dwagenk has quit [Quit: Bridge terminating on SIGTERM]
barath has quit [Quit: Bridge terminating on SIGTERM]
hmw[m] has quit [Quit: Bridge terminating on SIGTERM]
lexano[m] has quit [Quit: Bridge terminating on SIGTERM]
ejoerns[m] has quit [Quit: Bridge terminating on SIGTERM]
berton[m] has quit [Quit: Bridge terminating on SIGTERM]
jwillikers[m] has quit [Quit: Bridge terminating on SIGTERM]
jonesv[m] has quit [Quit: Bridge terminating on SIGTERM]
SalamaSalama[m] has quit [Quit: Bridge terminating on SIGTERM]
khem has quit [Quit: Bridge terminating on SIGTERM]
coldspark29[m] has quit [Quit: Bridge terminating on SIGTERM]
Jari[m] has quit [Quit: Bridge terminating on SIGTERM]
moto_timo[m] has quit [Quit: Bridge terminating on SIGTERM]
JosefHolzmayrThe has quit [Quit: Bridge terminating on SIGTERM]
hpsy[m] has quit [Quit: Bridge terminating on SIGTERM]
PascalBach[m] has quit [Quit: Bridge terminating on SIGTERM]
k4wsys[m] has quit [Quit: Bridge terminating on SIGTERM]
meck[m] has quit [Quit: Bridge terminating on SIGTERM]
jaskij[m] has quit [Quit: Bridge terminating on SIGTERM]
saYco[m] has quit [Quit: Bridge terminating on SIGTERM]
Nate[m]1 has quit [Quit: Bridge terminating on SIGTERM]
Spectrejan[m] has quit [Quit: Bridge terminating on SIGTERM]
fabatera[m] has quit [Quit: Bridge terminating on SIGTERM]
glembo[m] has quit [Quit: Bridge terminating on SIGTERM]
agherzan has quit [Quit: Bridge terminating on SIGTERM]
behanw[m] has quit [Quit: Bridge terminating on SIGTERM]
DanielWalls[m] has quit [Quit: Bridge terminating on SIGTERM]
azstevep[m] has quit [Quit: Bridge terminating on SIGTERM]
falk0n[m] has quit [Quit: Bridge terminating on SIGTERM]
WadeBerrier[m] has quit [Quit: Bridge terminating on SIGTERM]
ramprakash[m] has quit [Quit: Bridge terminating on SIGTERM]
cryptollision[m] has quit [Quit: Bridge terminating on SIGTERM]
olani[m] has quit [Quit: Bridge terminating on SIGTERM]
janvermaete[m] has quit [Quit: Bridge terminating on SIGTERM]
Markus[m]1 has quit [Quit: Bridge terminating on SIGTERM]
Alban[m] has quit [Quit: Bridge terminating on SIGTERM]
Vonter has quit [Ping timeout: 260 seconds]
jmlemetayer[m] has joined #yocto
<kanavin>
RP: I did run the script locally, but I would want to try again to be extra sure
jordemort has joined #yocto
Spectrejan[m] has joined #yocto
lexano[m] has joined #yocto
meck[m] has joined #yocto
Alban[m] has joined #yocto
kayterina[m] has joined #yocto
Emantor[m] has joined #yocto
khem has joined #yocto
shoragan[m] has joined #yocto
ejoerns[m] has joined #yocto
jonesv[m] has joined #yocto
dwagenk has joined #yocto
t_unix[m] has joined #yocto
moto_timo[m] has joined #yocto
azstevep[m] has joined #yocto
PascalBach[m] has joined #yocto
falk0n[m] has joined #yocto
k4wsys[m] has joined #yocto
coldspark29[m] has joined #yocto
barath has joined #yocto
jwillikers[m] has joined #yocto
behanw[m] has joined #yocto
Nate[m]1 has joined #yocto
wmills has joined #yocto
glembo[m] has joined #yocto
Barry[m] has joined #yocto
DanielWalls[m] has joined #yocto
hmw[m] has joined #yocto
Jari[m] has joined #yocto
fabatera[m] has joined #yocto
agherzan has joined #yocto
JosefHolzmayrThe has joined #yocto
ramprakash[m] has joined #yocto
<RP>
kanavin: ok, I think it might not work but I'm not 100% sure
janvermaete[m] has joined #yocto
Markus[m]1 has joined #yocto
<RP>
If anyone wants a laugh, the QA_SANE variable looks like a lovely and useful :(
cryptollision[m] has joined #yocto
olani[m] has joined #yocto
SalamaSalama[m] has joined #yocto
berton[m] has joined #yocto
jaskij[m] has joined #yocto
hpsy[m] has joined #yocto
saYco[m] has joined #yocto
ericson2314 has joined #yocto
WadeBerrier[m] has joined #yocto
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<RP>
Hmm, I see what it is doing and it is horrible :(
<vd>
besides NVMe, what matter the most for huge compilation job? number of cpu cores, per-core clock, ram amount, ram speed/latency? I feel like many cpu cores isn't necessary
manuel1985 has quit [Ping timeout: 265 seconds]
<kanavin>
RP: that seems correct, -L is needed
Tokamak has joined #yocto
frieder has quit [Remote host closed the connection]
<fray>
as you start optimiing for your workflows, you need to go back and reoptimize
<fray>
if you are doing a build of toolchains, I find cores and memory are more important than disk.. (but also a reasonable speed disk to start with is assumed)
<fray>
I got a lot less performance boost from an SSD then I did with more cores
<fray>
but in a "general OS" build, the dynamics change.. especially if you don't have webkit and other tools that can parallize well
<rburton>
vd: compiling is both CPU and IO bound, so lots of everything. You can mitigate slow I/O with more memory, a slower commit time, and building in tmpfs.
<RP>
kanavin: should I tweak the patch or wait for a resend?
<RP>
kanavin: I also just connected the dots with rust-native now being needed for sato to build. Painful build time :(
<fray>
ya, if money is no obsticle then I'd have lots of NVMe, 4 GB per core and at LEAST 64 cores..
<fray>
for MY workflow I find cores more beneficial then CPU speed, but that doesn't match other people's experiences
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<fray>
i.e. I'd rather have 32 2.4 Ghz cores then 16 3.2 Ghz cores..
<vd>
fray: I was looking for building a "powerful home router" for myself to replace my personal server and build on it, since I'm compiling OE images with QtWebEngine all day long, I cannot afford to wait 5h for an image anymore...
<fray>
when you bring webkit into the discussion, generally speaking, that seems to parallelize well.. so lots of cores are useful..
<rburton>
apart from the link
<rburton>
which is long and slow
<rburton>
and eats all the memory you can give it
<fray>
that last time I had a "large" machine available to me it was 192 threads (so half that for cores). Building webtkit at the time could consume up to about 164 of the threads at any given time..
<vd>
rburton: building in tmpfs is actually very smart. Do you place SSTATE_CACHE/TMPDIR in ram?
<fray>
(this was about 2 years ago)
<rburton>
no, they're on real disk
<rburton>
a good sstate is *huge* and you really don't want it to disappear on a reboot
<fray>
TMPDIR can be in the tmpfs, everything else (build directory wise) is on a "real" disk somewhere
<rburton>
yeah, sorry the build dir (TMPDIR) is tmpfs
<rburton>
conf, sstate, downloads are on real disk
<rburton>
just remember to allow executable files in the tmpfs, otherwise you get really weird errors :)
<fray>
yup
jwillikers has quit [Read error: Connection reset by peer]
florian has quit [Quit: Ex-Chat]
<fray>
my current workstation is a couple year old 32-core Xeon gold w/ 128 GB of ram and 2 SSD (sata) in a raid0... the ram and raid0 helped a lot..
<fray>
(I should say 2 16 core xeon golds of some kind)
<vd>
I feel like what fray is using is totally out of scope to me, I'm considering a ~$2k custom build to act as a home server, sshfs and build on it etc.
* vd
feels like fray is working in a Google datacenter :D
florian_kc has quit [Ping timeout: 252 seconds]
<fray>
Look into AMD CPUs.. 16 and 32 core isn't out of budget (in the $2K range) assuming you can actually find htem in stock..
<rburton>
yeah, stock is the problem right now!
<fray>
Intel CPUs are cheaper, but AFAIk the largest core is 24 right now
<vd>
rburton: what's the minimal ram amount requirement for TMPDIR in tmpfs?
jwillikers has joined #yocto
<fray>
but a 24 core (48 thread) with 128 GB of ram and NVMe would be a REALLY good builder
<fray>
With tmpfs on ramdisk, you pretty much need to use rm_work (so you keep cleaning up temp files as much as possible to save space)..
<rburton>
vd: if you use rm_work you can get away with something like 16gb most of the time. its when the system decides to build webkit *and* clang at the same time that you need to step in and do them sequentially.
<fray>
I know people who have done it on 128 GB ram machines, dedicting 64 GB to the build, but that was always tight in the configurations I built..
<fray>
rburton: ya, thats where I needed around 64 GB or more.. webkit and clang are both huge.. add to that additional things (if you have more cores)
<fray>
IF you can afford it, I'd say go with 256 GB of ram.. but if not, I'm pretty much in the 128 GB minimum these days (for any machine over 16 cores)
<rburton>
right, my new machine has 256gb of ram so 64gb of tmpfs is plenty for most things
<kanavin>
RP: I will send a tweaked patch
<fray>
and in the end it's all about tradeoffs.. if a slower CPU gives you some more money for ram.. I'd make that tradeoff
tnovotny has quit [Quit: Leaving]
_wmills has joined #yocto
<paulg>
I thought sstate was so awesome I could build on my 2012 vintage atom netbook.
<vd>
rburton: I feel like bitbake/OE may have site-specific option to specify the ram amount to use to automatically avoid building in parallel tasks like webengine and clang then :P
<fray>
ohh and for home use, you don't HAVE to have the current generation CPus either.. :) My home builder is a dual 24 core xeon system that is 8? years old now.. it's still plenty fast enough for what I do in my spare time.
<fray>
bitbake only handles number of concurrent threads.. and then the job schedular (make, ninja, cmake, etc) handles number of concurrent jobs..
wmills has left #yocto [#yocto]
<kanavin>
RP: sent
<vd>
fray: because space was a concern (small appartment) I was considering a mini itx build which is limited to 64Go RAM, I feel a bit stupid now that you're talking about going with 256Go ram... :)
<fray>
for the toolchain stuff I do, it's not unusual for me to have 300+ concurrnet tasks running [obviously the load is high enough it's noticable], but otherwise with enough ram and disk I/O seems to be slightly faster then if I'd just limited it to a small overall process count
_wmills is now known as wmills
<kanavin>
RP: sadly yes but rust-native should at least build only once for all targets
<fray>
for my own stuff, I have a 4U rack mount capable machine.. (really it juts means I can set it on it's side) but it's the size of a mini-tower..
<kanavin>
RP: we can drop gstreamer-plugins-bad from sato, or transition to weston images ;)
<fray>
my home router and server though.. is a 1 U small form factor.. the server part is running on a quad-core atom.. :)
<fray>
(my server basically handles DNS requests and email.. so again thread count vs overall speed is great in that configuration)
<rburton>
five year old xeons are still pretty fast, so a used workstation with choice upgrades is a budget option for sure
Vonter has joined #yocto
<vd>
interesting
<RP>
kanavin: I somehow thought you may say that. We may want to think about where we include the plugins...
<fray>
rburton: yup.. Intel Demo Depot (was given to me as surplus) CP2600.. :) "Free" builder.. I just had to supply the ram and disks.. (cost about $500 or so for the 'free' machine at the time)
<fray>
(was not given to me by Intel BTW, in case that comes up)
<fray>
rburton: HA! I have one of those at my office... :)
<rburton>
i liked it, pretty quiet considering the power
jwillikers has quit [Ping timeout: 245 seconds]
<fray>
ya.. the T5600's though the power supplies like to fail and take out the main board
<vd>
maybe making a custom build from scratch is just a waste of time and material, given that as you both said, "old" CPUs are still fast and recycling them seems perfect for home server/builder. Are they known website to refurbish such SFF machines?
<rburton>
fray: we'd upgraded the PSU to the highest spec and swapped the cores for the biggest xeons we could get
<fray>
Note with only the 'v3' CPus though I think it's limited to 160 or something
<fray>
ohh, and when it's running it's about as loud as a jet taking off
<rburton>
I remember RP saying he can see dust get sucked across the floor when his builder really ramped up the fan
<fray>
(if that sucker was $800 cheaper, I'd buy it) :) it's older but would be an amazing builder..
<RP>
rburton: cyclone vortex formed in the bay window and grabbed the curtains :)
<rburton>
haha
<rburton>
fray: only 192? pah
<fray>
rburton: I honestly needed ear plugs when my builder had a load over about 250..
Tokamak has joined #yocto
<fray>
that and the power consumption during builds was like 8 or 9 amps (@ 120V)
<rburton>
that dell was just a moderate hum even at full whack
<fray>
yup
<rburton>
nice bit of kit, and if i needed to buy a budget builder at home, that's what i'd get again i think
<fray>
one of the spare T5610s I had ended up at my dads.. he runs Quicken on it.. :P To load Windows 10 they MADE me buy the pro version cause the motherboard has two CPU sockets
<fray>
:P
<rburton>
ha
<rburton>
somewhat hardware overkill
<vd>
rburton: which one? the Dell T5610?
<rburton>
yes
<fray>
"just a little bit".. but it was better then his circa 2005 AMD laptop
<vd>
"budget home SFF builder" might describe more what I'm looking for
<fray>
but ya, you can buuld yourself something.. or take the disk on used hardware that is a bit older.. the used hardware (assuming no faults) you'll likely get a better overall experience and performance
<vd>
for context, I'm currently building all day long on my i5-8250U/16Go RAM/500Go NVMe laptop...
<fray>
take the _risk_
<fray>
that's honestly not a bad config...
<fray>
other then my laptop.. (including work machines) I think the newest CPUs I have access to are at least 3 years old at this point..
<fray>
and they really are "good enough"
<vd>
fray: maybe I could optimize the build as rburton suggested but I don't think 16Go RAM is enough to place TMPDIR in tmpfs from what I understand :/
<fray>
no it won't be enough.. you'd definitely need more ram then that
<vd>
fray would 64Go be an option or still not sufficient?
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<fray>
probably still too small.. MY experience is 128 is the minimum if you want to use the ramdisk
<fray>
again, my experience may not be typical for your workflow though
<fray>
(my workflow is full OS builds and _very_ large toolchain builds)
<fray>
very large toolchain builds, building for multiple CPUs and multiple library configurations... so the toolchain stuff parallizes REALLLY well
<vd>
fray: I'm doing full OS builds for embedded devices, including qtwebengine, nothing too fancy, but still around five hours to build from scratch...
<vd>
I feel like ramdisk with rm_work and TMPDIR in tmpfs is the way to go for a modest home builder that doesn't shred my curtains, correct?
<halstead>
kanavin: We are setting up a new email relay which is the first step to resolving the problem. . It will be ready to test tomorrow.
<kanavin>
halstead, thanks :)
jmiehe has quit [Ping timeout: 245 seconds]
<rburton>
vd: if you're not doing huge builds, you'll be fine with 64gb. my dell had 64gb, 32gb of tmpfs.
<vd>
rburton: what happens if you somehow need more than 32gb for your tmpfs? e.g. if bitbake builds both huge recipes at the same time like you mentioned?
<rburton>
i build one on its own, then the other
<vd>
rburton: this means that the build would've failed with no space left on the tmpfs device, right?
<rburton>
yes
BCMM has joined #yocto
florian_kc is now known as florian
<vd>
Any preferences regarding AMD EPYC™ 3000-series vs Intel® Xeon® D-2100?
Vonter has quit [Ping timeout: 265 seconds]
<JosefHolzmayrThe>
ah is it "discuss your next YP build machine" time again?
mvlad has quit [Remote host closed the connection]
florian has joined #yocto
GillesM has joined #yocto
Guest52 has joined #yocto
Tokamak has joined #yocto
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
GillesM has quit [Quit: Leaving]
bps has quit [Ping timeout: 265 seconds]
<vd>
rburton: fray: with 2x64Go RAM and 1To NVMe it's $3k CAD for this 8-core/16-thread.
sgw has joined #yocto
xmn has joined #yocto
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
* RP
mailed the swat list with more debug. Anyone good at debugging make deadlock hangs in perl's makefiles?
Tokamak has quit [Read error: Connection reset by peer]
Guest31_niclas has joined #yocto
florian has quit [Ping timeout: 252 seconds]
Tokamak has joined #yocto
<Guest31_niclas>
Hello. I am trying to use 5 or more yoctopuce sensors connected to a pi 4B. Everything works fine with only 4 sensors connected, but if I connect a fifth sensor the USB interface completely stops responding for several seconds at a time and only sporadically manages to perform some work. I am using 2 yocto usb hubs, but have also tried with other
<Guest31_niclas>
hubs. Hope I explained the issue well enough.. Any ideas?
<smurray>
Guest31_niclas: this channel is for discussion of https://www.yoctoproject.org/, which is a software project. Interesting name collision, though, I'd not heard of yoctopuce before
leon-anavi has quit [Quit: Leaving]
<Guest31_niclas>
haha, really? Wow my apologies. I'll try find the other yocto im looking for, thanks anyway, and thanks for quick response
florian has joined #yocto
florian has quit [Ping timeout: 268 seconds]
tgamblin has quit [Quit: Leaving]
BCMM has quit [Quit: Konversation terminated!]
Tokamak has quit [Ping timeout: 252 seconds]
Tokamak has joined #yocto
davidinux has quit [Ping timeout: 245 seconds]
mckoan|away has quit [Ping timeout: 265 seconds]
florian has joined #yocto
yocti has joined #yocto
manuel1985 has joined #yocto
Tokamak has quit [Ping timeout: 252 seconds]
Tokamak has joined #yocto
<Ch^W_>
If I have a SRC_URI += "file://src;subdir=${S}" and I have src/foo/bar/baz and I update a subdirectory to src/foo/bar2/baz (but do not change any actual file content), it does not appear as if bitbake is catching on that a change was made.