otavio has quit [Remote host closed the connection]
vagaruy has quit [Ping timeout: 250 seconds]
mihai- has joined #yocto
mihai has quit [Ping timeout: 250 seconds]
vagaruy has joined #yocto
d0ku has joined #yocto
d0ku has quit [Ping timeout: 240 seconds]
vagaruy has quit [Quit: Ping timeout (120 seconds)]
vagaruy has joined #yocto
rpcme has quit [Ping timeout: 246 seconds]
<vmeson>
name a recipe that compiles 1000s of files and uses just make rather than cmake or meson? The kernel and ... ?
<vagaruy>
gcc?
<vmeson>
vagaruy: ah, could be! I was stuck on applications and most have switch to cmake/ninja. Thanks.
<vagaruy>
qemu too
<vmeson>
vagaruy: right. Do you have to have any idea which would generate a higher load offhand?
<vmeson>
I'm playing with the 'make/ninja -l <NUM>' limits and trying to see if make's more responsive calculation of load average is observable / significant.
<vmeson>
My reference is chromium but it's build is a beast and it flatlines a 192 core system pretty much through the whole build it seems. I'll have a nice graph is a bit... :)
sakoman has quit [Quit: Leaving.]
sakoman has joined #yocto
whuang0389 has quit [Quit: Client closed]
xmn has joined #yocto
vagaruy has quit [Ping timeout: 252 seconds]
cocoJoe has joined #yocto
vagaruy has joined #yocto
Ad0 has quit [Ping timeout: 250 seconds]
Ad0 has joined #yocto
amitk has joined #yocto
tp43_ has quit [Ping timeout: 250 seconds]
rber|res has joined #yocto
tp43_ has joined #yocto
xmn has quit [Quit: ZZZzzz…]
paulg has quit [Ping timeout: 250 seconds]
sakoman has quit [Quit: Leaving.]
goliath has joined #yocto
dtometzki has joined #yocto
tp43_ has quit [Ping timeout: 250 seconds]
goliath has quit [Quit: SIGSEGV]
frieder has joined #yocto
rob_w has joined #yocto
camus has quit [Ping timeout: 250 seconds]
camus has joined #yocto
leon-anavi has joined #yocto
sbach has quit [Read error: Connection reset by peer]
sbach has joined #yocto
<RP>
vmeson: down to one reproducibility failure on that last build
tre has joined #yocto
zpfvo has joined #yocto
d0ku has joined #yocto
LetoThe2nd has joined #yocto
vagaruy has quit [Quit: Ping timeout (120 seconds)]
vagaruy has joined #yocto
tnovotny has joined #yocto
sgw has quit [Ping timeout: 240 seconds]
goliath has joined #yocto
sgw has joined #yocto
grma has quit []
grma has joined #yocto
<LetoThe2nd>
what are ways to feed a sstate cache on s3 or comparable, for example?
hmw[m] has quit [Quit: You have been idle for 30+ days]
<mbrothers>
Good morning! I have inherited a yocto distribution which is used to build a distro for two devices. Now there's a configuration difference between the two. The first device does have its OS and configuration on
<mbrothers>
the same partition, but the second device has the configuration stored in a different partition and everything is symlinked. For a specific package (openvpn) we need to have this configuration to be symlinked as
<mbrothers>
well. So someone thought it was a good idea to use the do_install_append function for this, but this won't work for the first device. Is there a way to distinguish between these two devices at compile time and NO
<mbrothers>
T execute this append function for the first device? Or do I have to create a seperate layer for these? Thanks for your time!
<LetoThe2nd>
mbrothers: should be easy to distinguish via overrides.
<LetoThe2nd>
wCPO: this is not exactly a yocto problem to support. if you have a compiler that can support it, then you can always set the corresponding flags.
<LetoThe2nd>
wCPO: read this as: if there's software that sued it, YP can usually be used to build it. this does not necessarily mean that all the needed pieces are freely available out in the wild, though.
<wCPO>
LetoThe2nd: I see, I'm still learning yocto. So basically setting TARGET_CC_ARCH or TUNE_CCARGS in a new tune file used by TUNE_ARCH?
<LetoThe2nd>
wCPO: something along those lines, probably. i'd suggest looking at the existing tune files for inspiration.
Vonter has joined #yocto
<RP>
zeddii: its a bigger glitch, I've dropped the patches and will let you figure out what broke...
kayterina has joined #yocto
<mbrothers>
LetoThe2nd I think I know what you mean if we just need to copy in some files, but about symlinks linking to ${D}${sysconfdir}/some_config? If I want to use OVERRIDE on files, then I need to have those symlinks already in place pointing to somewhere, isn't it?
<mbrothers>
Or am I thinking too dificult now? I can also make the symlinks pointing to where they need to point to on the target and just copy them onto the image... Is what happens now after running bitbake
<LetoThe2nd>
mbrothers: no, i was thinking about having two seperate install appends depending on the distro.
<LetoThe2nd>
Guest32: but its actually of rather limited value unless you really stick to poky, with standard configuration and almost no additional layers.
<Guest32>
LetoThe2nd good to know
<LetoThe2nd>
i personally have never used it, other than a simple try if it actually works.
Ad0 has joined #yocto
<Guest32>
I thought (initially before your response) that it was a great advantage because it states, and I cite, "You can significantly speed up your build and guard against fetcher failures by using mirrors."
<Guest32>
This yocto chat is really helpful for everyone to master it.
<qschulz>
Though it's a bit less useful since dunfell because of the hashserv thing
<qschulz>
so only 55% of the sstate-cache will match on a vanilla poky
<qschulz>
and I don't remember if among the 45 remaining percents there are importnat native recipes triggering a full rebuild
<wCPO>
I'm trying to install ovmf for runqemu per the commit instructions with MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "ovmf" in my machine conf file, but it just fails with "- nothing provides ovmf needed by packagegroup-core-boot-1.0-r17.mukube". Any ideas?
<LetoThe2nd>
Guest32: qschulz: yeah exactly. once a custom machine comes into play the public sstate is mostly useless, IMHO
xmn has joined #yocto
zyga-mbp has joined #yocto
eduardas has quit [Ping timeout: 250 seconds]
eduardas has joined #yocto
<mbrothers>
LetoThe2nd: The override also works for those things? Cool! So that would become something like (and now I have to read the slides very careful!) do_install_append_device_1 and do_install_append_device_2 where device_1 and device_2 are my machine configuration names?
<LetoThe2nd>
mbrothers: i *think* thank sould work, yes.
<qschulz>
yeah that works just fine
<qschulz>
though try to not have underscores in any recipe filename or machine name
linkliu59 has quit [Ping timeout: 250 seconds]
linkliu59 has joined #yocto
lucaceresoli has quit [Ping timeout: 240 seconds]
paulg has joined #yocto
<LetoThe2nd>
qschulz: yeah, lodash is better anywways.
<rfs613>
has anyone built dunfell branch under latest debian (bullseye)?
mihai- is now known as mihai
camus has quit [Quit: camus]
<vmeson>
vagaruy: qemu uses ninja now too, fyi. gcc's build is not well behaved (configures during make, doesn't pass make flags to children) so I"m still looking for something similar in scale to chromium that uses 'make'.
<zeddii>
RP: I fixed up my misfiring script. It is just the one 5.13.12 update that was off the rails. Did you want me to resend the full pull request, or just a v2 of that one patch ?
Vonter has quit [Ping timeout: 240 seconds]
<RP>
zeddii: whichever is easier. I suspect that but decided to let you double check the patches :)
Vonter has joined #yocto
d0ku has joined #yocto
bps has quit [Ping timeout: 240 seconds]
Vonter has quit [Read error: Connection reset by peer]
Vonter has joined #yocto
<tlwoerner>
qschulz: we'll need an updated presentation for the next yps ;-)
<tlwoerner>
feel free to start on the slides now ;-)
<qschulz>
s/_/:/ should suffice
<LetoThe2nd>
qschulz: hi5
argonautx has joined #yocto
camus has joined #yocto
davidinux has quit [Ping timeout: 240 seconds]
davidinux has joined #yocto
goliath has quit [Quit: SIGSEGV]
bantu has quit [Quit: bantu]
bantu_ has joined #yocto
Vonter has quit [Ping timeout: 240 seconds]
mbrothers has quit [Ping timeout: 252 seconds]
Vonter has joined #yocto
<OutBackDingo>
zeddii: ping
zyga-mbp has quit [Ping timeout: 250 seconds]
zyga-mbp has joined #yocto
<RP>
zeddii: btw, I mention to mention those IDENTIFY issues are both systemd
vagaruy has quit [Quit: Connection closed]
dev1990 has joined #yocto
zpfvo has quit [Remote host closed the connection]
eduardas has quit [Quit: Konversation terminated!]
zeddii has quit [Remote host closed the connection]
tnovotny has quit [Quit: Leaving]
zeddii has joined #yocto
florian has quit [Quit: Ex-Chat]
<vd>
I see various approaches for SRC_URI, some with +=, some with _append :=, is one preferred?
goliath has joined #yocto
override is now known as Guest9844
<RP>
vd: += would be the nicest but doesn't always work
override1 is now known as override
frieder has quit [Remote host closed the connection]
d0ku has quit [Ping timeout: 252 seconds]
mattsm has quit [Remote host closed the connection]
mattsm has joined #yocto
amitk has quit [Ping timeout: 250 seconds]
LetoThe2nd has quit [Quit: Connection closed for inactivity]
florian has joined #yocto
<moto-timo>
RP: there's an upstream commit to pytest that should be the fix. testing now
florian has quit [Ping timeout: 250 seconds]
zyga-mbp has quit [Ping timeout: 252 seconds]
zyga-mbp has joined #yocto
davidinux has quit [Ping timeout: 250 seconds]
bps has joined #yocto
bps has joined #yocto
lucaceresoli has quit [Quit: Leaving]
sethfoster has quit [Ping timeout: 250 seconds]
<kanavin>
halstead, I wrote a comment that hopefully better explains what the problem is with virgl
<kanavin>
you don't really need to do this on every host
davidinux has joined #yocto
sethfoster has joined #yocto
ferlzc has joined #yocto
zyga-mbp has quit [Ping timeout: 248 seconds]
<moto-timo>
RP: fix for python3-jinja2 ptest sent to ML
<moto-timo>
RP: all python3-jinja2 ptests passed locally
d0ku has joined #yocto
zyga-mbp has joined #yocto
<ferlzc>
Hi guys, i'm building an image on yocto 3.3 hardknott branch.
<ferlzc>
I want to use openssh and be able to ssh to my device using my custom image. After my customization on Yocto, the ssh package is instaled on the image but the server service is not running.
<nick>
I am trying used devtool to build libaacplus library but my build doesn't find unzip tool
<nick>
does anyone have any advice to solve this problem?
nick has quit [Quit: Client closed]
oprata has joined #yocto
leon-anavi has quit [Remote host closed the connection]
<oprata>
hello folks!
leon-anavi has joined #yocto
<oprata>
I had a problem to use devtool to build libaacplus. During the configuration devtool show a error because unzip package is missing.
<oprata>
Does anyone know how fix it?
prabhakarlad has quit [Quit: Client closed]
davidinux has quit [Ping timeout: 240 seconds]
davidinux has joined #yocto
<kanavin>
it helps if you show the error
davidinux has quit [Ping timeout: 240 seconds]
davidinux has joined #yocto
<oprata>
I used this command to build: $devtool build libaacplus
<oprata>
This is the error
<override>
is there a knowm / preferred way of changing where the device tree is read in from? any utils/known schemes, or mechanisms
<oprata>
| configure: error: You need unzip utility to prepare sources.
<oprata>
| WARNING: exit code 1 from a shell command.
<oprata>
|
<oprata>
ERROR: Task (/home/developer/repos/allwinner/nanopi-neo-plus2/workspace/recipes/libaacplus/libaacplus_git.bb:do_configure) failed with exit code '1'
<kanavin>
oprata, the error is coming from component's configure script - you need to read the script to see what is it trying to do - probably a dependency in recipe for unzip-native is needed
<oprata>
thanks a lot. I will try this.
<oprata>
The error change a little bit
<oprata>
This is the new error
<oprata>
| checking for unzip... /home/developer/repos/allwinner/nanopi-neo-plus2/tmp/work/aarch64-allwinner-linux/libaacplus/2.0.2+git999-r0/recipe-sysroot-native/usr/bin/unzip
<oprata>
| checking for patch... /home/developer/repos/allwinner/nanopi-neo-plus2/tmp/work/aarch64-allwinner-linux/libaacplus/2.0.2+git999-r0/recipe-sysroot-native/usr/bin/patch
<oprata>
| checking for /bin/bash... configure: error: cannot check for file existence when cross compiling
<oprata>
| WARNING: exit code 1 from a shell command.
<oprata>
|
<oprata>
Should I build the sdk first before use devtool to build my own recipe?
sakoman has joined #yocto
zyga has quit [Ping timeout: 252 seconds]
<kanavin>
oprata, no - you do need to look into what configure script really does, as SDK contains the same cross-toolchain and will likely throw the same errors
<kanavin>
you probably do not need native-sdk inherit
<kanavin>
oprata, libaacplus is obsolete, and unmaintained
<kanavin>
sorry but you need to find a different way to do what you want
<oprata>
Do you known which lib replace libaacplus?
zyga-mbp has quit [Ping timeout: 252 seconds]
cocoJoe has quit [Quit: Client closed]
zyga-mbp has joined #yocto
<JaMa>
smurray: ping
rpcme has quit [Quit: Client closed]
<JaMa>
smurray: wrt that prserv issue, it happens only with localhost:0, if I use e.g. PRSERV_HOST = "localhost:8585" then it's fine and the port when it's failing is set, but to 0 and self.prserv.address is what's undefined
vd has quit [Quit: Client closed]
<smurray>
JaMa: okay, I'm good with adding error checking, but just to check, am I correct in believing that localhost:0 shouldn't work since that's an invalid port #?
<smurray>
JaMa: just wondering if there's some container magic that might make it valid ;)
<smurray>
JaMa: right, but my question is if you specify PRSERV_HOST = "localhost:0", do you expect it to work, or fail with an error message?
<smurray>
JaMa: I'm assuming the latter, but wanted to double-check I'm not missing something
<JaMa>
local.conf.sample says it should work and autostart PRSERV, but using port 0 seems a bit strange
<smurray>
ah, okay. That does seem odd, since if it ignores the 0, you'd then need to look at the log to figure out what port it's using
<JaMa>
I was assuming that asyncio.start_server is supposed to select some random port, return it to self.server and then it's set as a prserv port from the socket, but in this case it looks like asyncio.start_server never finishes (as the logger message with 'sockets:' isn't ever called)
<override>
any runtime device tree update mechanisms? be great if someone could link to me some yocto preferred ways of doing device tree updates...
<JaMa>
and because it never reaches this line, it never sets the prserv.address (which then causes the rsplit() to fail
<JaMa>
let me try without docker :)
<smurray>
JaMa: okay, it's probably generically broken, I suspect
<RP>
smurray: I'm fairly sure "0" means pick a random port and autostart on that
<RP>
basically for duration of the current build
<smurray>
yeah, I'm guessing passing that down to asynio's start_server might be broken in some situation
<JaMa>
works locally without the docker NOTE: Started PRServer with DBfile: /OE/build/oe-core/cache/prserv.sqlite3, Address: 127.0.0.1:42005, PID: 103771
<smurray>
ah, that's interesting. htm
<smurray>
err, hrm
<JPEW>
JaMa: are you using --net=host ?
leon-anavi has quit [Quit: Leaving]
<JPEW>
(or maybe docker blocks binding to ephermal ports for some reason)
<smurray>
JaMa: if you let me know what distro you're running in that container, I can poke at trying to root cause it here
<FO>
PRSERV_HOST = "localhost:0" used to work for us before dunfell; then we had to remove it
WadeBerrier[m] has joined #yocto
rpcme has joined #yocto
<JaMa>
smurray: ubuntu:hirsute
<FO>
but cant run 2 build at same time with it anymore since dunfell
<JaMa>
JPEW: no, not --net=host
<smurray>
JaMa: okay, I'll try rigging something up tomorrow, and work up at least a patch to better catch it failing out
<JPEW>
JaMa: Ya, I was misthinking. That (should?) be ok as long as you aren't trying to access the server outside the container
<JaMa>
I've switched to 20.04 ubuntu and the same
wberrier has joined #yocto
wberrier has left #yocto [#yocto]
<tlwoerner>
zeddii: out of curiosity, why is the kmeta branch for 5.13 not aligned with the HEAD commit?
argonautx has quit [Quit: Leaving]
sethfoster has quit [Quit: leaving]
fullstop_ has joined #yocto
halstead_ has joined #yocto
xantoz_ has joined #yocto
halstead[m]1 has joined #yocto
fullstop has quit [Excess Flood]
xantoz has quit [Ping timeout: 276 seconds]
halstead[m] has quit [Ping timeout: 276 seconds]
halstead has quit [Ping timeout: 276 seconds]
fullstop_ is now known as fullstop
halstead_ is now known as halstead
<JaMa>
smurray: looks like I have an work around for this, will send a patch to ML
<smurray>
JPEW: heh, any idea why that'd make a difference ^ ?
otavio has joined #yocto
<JPEW>
Only thing I can think of is that self.loop isn't the default loop for some reason when that is called
<JPEW>
Oh, hmm, ya. That is really strange
<JPEW>
JaMa what python version are you using in the container?
<JaMa>
$ python3 --version
<JaMa>
Python 3.9.6
<vmeson>
moto-timo: noted but it's EOD for me today.
<moto-timo>
vmeson: just FYI. enjoy your evening
<vmeson>
moto-timo: thanks, later.
prabhakarlad has joined #yocto
<JaMa>
JPEW: smurray: I'm sorry, looks like this change doesn't fix the issue in the end, I've switched to --net=host when switching between 21.04 and 20.04 ubuntu and that resolves the issue, after dropping --net=host again I can reproduce it again with both versions even with this commit (20.04 has python3 3.8.10)
<JPEW>
JaMa: OK. I wonder if docker is blocking ephermal ports somehow
<JaMa>
JPEW: bitbake-prserv works OK which does almost the same as the "autostarted" one, right? with bitbake@0064d3a94913:~/nodistro/honister$ bitbake-prserv --start --host=127.0.0.1 --port=42005
<JPEW>
I would think so? The difference (as far as I know) is the attempt to use an automatic ephermal port
<JaMa>
ah it doesn't like "localhost" as it's resolved to IPv6
<JaMa>
OSError: [Errno 99] error while attempting to bind on address ('::1', 42005, 0, 0): cannot assign requested address
<JaMa>
is in prserv.log after bitbake-prserv --start --host=localhost --port=42005
<JPEW>
JaMa: Hmm, that sounds really familiar....
<WadeBerrier[m]>
any suggestions about using local modifications to bitbake/poky for a project? Background: we reference upstream poky git repo as readonly, but we've recently needed to make a bitbake modification (that we plan to push upstream). But, I'm assuming it will take a while for that to trickle down into the poky repository? How do folks use a modified bitbake? (or really, any local changes to the poky repository). In this case, it's a new
<WadeBerrier[m]>
fetch2 module.
wberrier has joined #yocto
<JPEW>
WadeBerrier[m]: Not that this is the best option, but we fork the repo with a local mirror and I make people upstream the change before I'll pull it back to the mirror :)
wberrier has left #yocto [#yocto]
<WadeBerrier[m]>
JPEW: We're considering something similar (basically implementing policy on our side). I do appreciate the feedback of what others are doing.
<JPEW>
JaMa: This may be why we make hashserver use a unix domain socket for the "auto" option
<JPEW>
JaMa: It would probably be much easier to make prserv do that now that it uses the common async code
<smurray>
JPEW: I was toying with that possibility when I was looking at the code, but figured less change would be better
<JPEW>
WadeBerrier[m]: The other approach we have is a parallel ".fixes" layer for each layer we pull in. You can do a suprising amount of fixups with .bbappends (but not everything, like a new fetcheer)
<JaMa>
JPEW: if I modify lib/prserv/serv.py to handle 127.0.0.1:0 the same as localhost:0 and to pass 127.0.0.1 to asyncio.start_server() then it seems to work
<JPEW>
JaMa: Hmm
oprata has quit [Quit: Client closed]
<JaMa>
I also remember explicitly disabling ipv6 in /etc/docker/daemon.json on some of my builders (but not on this one)
<smurray>
JaMa: that suggests it's specifically localhost resolving to a IPv6 address than make sit unhappy, maybe?
<JaMa>
smurray: yes
florian has joined #yocto
<smurray>
heh, what are the odds something's broken in upstream Python? ;)