Wouter0100 has quit [Remote host closed the connection]
Wouter0100 has joined #yocto
camus has quit [Ping timeout: 240 seconds]
sakoman has quit [Quit: Leaving.]
camus has joined #yocto
camus has quit [Remote host closed the connection]
camus has joined #yocto
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #yocto
amitk has joined #yocto
jclsn72 has joined #yocto
jclsn7 has quit [Ping timeout: 240 seconds]
jclsn72 is now known as jclsn7
Thorn has quit [Ping timeout: 240 seconds]
Thorn has joined #yocto
pgowda_ has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 240 seconds]
camus1 is now known as camus
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
kroon has joined #yocto
Guest22 has joined #yocto
<Guest22>
good morning
<Guest22>
was wandering if anyone has a dunfell commit number concerning update to 5.15 kernel as I cannot seem to find one, maybe that particular kernel revision was skipped?
Etheryon has joined #yocto
dtometzki has quit [Ping timeout: 256 seconds]
GNUmoon has quit [Ping timeout: 240 seconds]
rob_w has joined #yocto
frieder has joined #yocto
manuel1985 has quit [Ping timeout: 252 seconds]
goliath has joined #yocto
mckoan_ is now known as mckoan
<mckoan>
good morning
<hmw[m]>
good moring
lucaceresoli has joined #yocto
camus has quit [Ping timeout: 256 seconds]
camus has joined #yocto
<jclsn[m]>
Buenos dias
<dv__>
there's no yocto 3.5 release schedule page, so I ask here - what's the planned release date for kirkstone? I just know "sometime in april"
GNUmoon has joined #yocto
prabhakarlad has joined #yocto
manuel1985 has joined #yocto
mvlad has joined #yocto
fabatera[m] has quit [Quit: You have been kicked for being idle]
<Emantor>
rburton: we have our own kernel recipe which does not create -dbg packages. I'll peek at linux-yocto to see how its done.
leon-anavi has joined #yocto
florian has joined #yocto
<RP>
Why when trying to make a release build do we get a parade of errors which we haven't seen for months? :/
<Saur[m]>
RP: Murphy's law?
<RP>
Saur[m]: yes :(
barometz has quit [Quit: you can't fire me!]
barometz has joined #yocto
barometz has quit [Client Quit]
ctxnop has joined #yocto
barometz has joined #yocto
<ctxnop>
Hello! I have an issue with some pre-built libs that I try to install on an image. It seems that bitbake alters the lib right before creating the image. I supposed its a strip operation, unfortunately this lib seems to check some kind of checksum or something. So I added INHIBIT_SYSROOT_STRIP = "1" to my local.conf, INHIBIT_PACKAGE_STRIP = "1" and
<ctxnop>
INHIBIT_PACKAGE_DEBUG_SPLIT = "1" to the package recipe. but still append to be altered. Any idea?
pasherring has joined #yocto
<pasherring>
Hey there, good day, yoctoers! When I start a 'devtool modify', is it possible to do 'devtool finish' without propagating changes to the recipe/tree?
<Saur[m]>
pasherring: You mean like `devtool reset`?
<pasherring>
Saur[m], not sure, maybe that is what I am looking for --'
<pasherring>
I'll give it a try, as soon as my build finishes :)
olani has joined #yocto
<pasherring>
Saur[m], alrighty, it was exactly that. Thanks for the info
<ctxnop>
I read this exact documentation, and end-up to add the line to my local.conf because was not working
<rburton>
definitely don't add to local.conf
<ctxnop>
Yes I have image-prelink
<rburton>
that just pulls in the code, but doesn't turn it on
<rburton>
no, i'm wrong, inheriting the class does turn it on
<rburton>
don't do that :)
<rburton>
prelinking involves changing every library
<rburton>
also, it's barely a win, and doesn't exist in the next release
starblue has quit [Ping timeout: 240 seconds]
<ctxnop>
I know nothing about prelink, didn't set up this image in the first place, just getting over the job of someone who left. will read the doc about this to know if I can get rid of it without side effects
starblue has joined #yocto
<ctxnop>
If I'm correct it seems to speed up build time, but that's it. I'll give a try to disabling this feature, thanks a lot for this pointer
<rburton>
it does a partial runtime link ahead of time
<rburton>
totally destroys some security features, and modern loaders are so much faster
<rburton>
and latest glibc doesn't support it at all
<rburton>
basically, just turn it off
<ctxnop>
The thing is that we currently building using an old version (dunfell) based on the work of someone who left. Nobody maintained it. So now I have to take everything back and maintain old images, but I also started a migration on the next yocto's LTS. So I can do whatever I want on this new image. But I have to justify any little change on olds
<ctxnop>
ones.
<ctxnop>
Anyway, will be easy to justify the change if it just can't work without it ^^'
<rburton>
breaks address randomisation and silent corruption sound like good reasons to drop it ;)
<ctxnop>
I think so yes, thank for this link :)
<ctxnop>
Just finished to build, disabled prelink. everything worked like a charm, problem solve, thanks a lot
<rburton>
RP: argh the cve report!
<rburton>
ah terrible CPEs for the libsolv ones
olani has quit [Ping timeout: 250 seconds]
kroon has quit [Quit: Leaving]
lucaceresoli has quit [Remote host closed the connection]
lucaceresoli has joined #yocto
ctxnop has quit [Quit: Client closed]
florian has quit [Ping timeout: 256 seconds]
<RP>
rburton: yes, I had a quick look yesterday and think the libsolv ones are bad entries. The qemu ones look weird too, the patches mentioned were applied so I'm not sure 6.2.0 does have those issues
<rburton>
found a statement from the solv maintainer saying all the CVEs are fixed by a specific commit so that should be fixed today
<rburton>
seatd upgrade is trivial and safe as its just the fix
cb5r has joined #yocto
<RP>
rburton: cool. Which leaves qemu...
<RP>
oh, and vim
* RP
is trying to ignore that
<rburton>
now we're meant to be freezing, randomly upgrading vim is less attractive
<rburton>
i was hoping they'd release at some point
<kanavin>
rburton, we should probably file a bug and politely ask for a sane version policy
<rburton>
RP: the qemu one i looked at says up-to(excluding) 6.2.0, so either the cpe data changed since the report run or we just found a bug in the tool
<RP>
rburton: thanks, I don't quite understand why that suddenly showed up :/
otavio has quit [Read error: Connection reset by peer]
otavio has joined #yocto
<rburton>
RP:mailed nist
<RP>
rburton: thanks
<rburton>
khem: drop the blive* patches in master-next, the correct fix is to use setuptools_legacy
<RP>
rburton: the sstate patch from Jose is interesting re: the fetch issues we've seen
<rburton>
yes!
otavio has quit [Read error: Connection reset by peer]
otavio has joined #yocto
cperon has joined #yocto
Guest22 has quit [Quit: Client closed]
vladest has quit [Quit: vladest]
vladest has joined #yocto
prabhakarlad has quit [Quit: Client closed]
davidinux has quit [Ping timeout: 250 seconds]
florian has joined #yocto
davidinux has joined #yocto
cb5r has quit [Ping timeout: 240 seconds]
camus has quit [Remote host closed the connection]
camus has joined #yocto
actia has joined #yocto
<actia>
Hello
<actia>
I use yocto thud with a local mirror on Nexus 3 server, when I use PREMIRRORS_prepend with an url with basic authentication the username is replaced by usernamegit. Do you know how to fix this error ?
actia is now known as YourNick
YourNick is now known as actia
paulg has joined #yocto
<actia>
Do you know where is located the code of the fetch tash that handle premirror directive ?
paulg has quit [Remote host closed the connection]
vd is now known as vvn
<RP>
actia: bitbake/lib/bb/fetch2/__init__.py
paulg has joined #yocto
<actia>
Thanks RP
sakoman has joined #yocto
<zeddii>
heh. started a build last night on my home builder. I see cargo-native is still doing something 7 hours later
<zeddii>
947886 bruce 20 0 1241400 347952 98428 S 0.0 2.2 0:31.84 rustc
<zeddii>
'dat thing is memory hungry
<paulg>
yeah - as I was complaining before - the whole rust/cargo thing effectively killed off any older hardware with less than 16G RAM acting as builders
<zeddii>
yah. unfortunately, my home builders are older dell servers, this one only has 16G, hence I suppose why I thought it was dead
<zeddii>
not really enthusiastic about buying ram for this old beastie.
<zeddii>
it looks like it chose to OOM the wifi agent a few times. heh. I guess that explains the connection drop
Guest22 has joined #yocto
<Guest22>
greetings all
<Guest22>
how do i delete the pre-fetched kernel as it does not seem to issue a git pull and I cannot get my latest changes in
<paulg>
I was toying with the idea of looking at the task dispatcher and seeing if there was a quick and dirty way to teach it to not dispatch any new tasks if it senses that swap is in active use.
<Guest22>
tried bitbake -b <linux-kernel recipe> -c clean but yocto obviously gets it back from a cache as the new file is not there
<zeddii>
paulg: that might help, yah, I see now, only this morning it is finishing up libsrvg-native
<JPEW>
paulg: Or load-average maybe?
<zeddii>
and it only seems to have woken up, after I smashed my way onto the machine.
<paulg>
i.e. "use make -j4 and have 4 tasks in flight ... *iff* you can w/o touching down into swap."
<paulg>
an unchecked 4x4 will just kill things once it stumbles into the workfest of cargo/rust and oom your kit.
<paulg>
my "solution" so far has been just to blacklist all the stuff that has dependency chains that stumble into that rathole.
<paulg>
JPEW, I'm not sure loadavg will reflect whether you are in a swapdeath hell with the disk LED solid.
<zeddii>
I'm still seeing the icon themes blow up. it definitely needs to be serialized through that pit of hell.
<zeddii>
s/blow up/build/
<paulg>
the other option would be just to flag some packages as "please serialize me" - and then respect that flag for machines with 16G or less?
<paulg>
could put the kernel, glibc, rust, cargo, .... in there?
<zeddii>
yah. that's what I was thinking. like the "no migrate" or critical section flags in the kernel.
<paulg>
pretty much. I've never looked at the oe task dispatcher, so I have no idea how hard it would be to translate my random ideas into a working prototype...
<paulg>
but the rust/cargo stuff shines a bright light on how it fails miserably on giant behemoth ram-sucking package builds.
<qschulz>
Guest22: SRCREV is usually the variable stating which commit to check out in the recipe
<Guest22>
qschulz: yup just figured out that one ;-)
<zeddii>
Guest22: if you really are using -b you probably don't want to. it is almost never the right flag to use
<paulg>
I suppose you wouldn't even need to serialize the whole package - just the do_compile.
<zeddii>
paulg: yah
<paulg>
COMPILE_EXCLUSIVE=1
<paulg>
if set, don't dispatch any new do_compile tasks.
<zeddii>
not knowing anything either. sounds feasible.
<paulg>
I need to retire so I have time to chase random ideas like that. :-P
<actia>
I have identifie a bug in the fetch task, if I use SOURCE_MIRROR_URL with a basic authentivcation in the url : user:password@domain.com/REPO/SRC the command wget uses usergit instead of user for the authentication.
<actia>
Is it a know issue ?
<actia>
I think there is a bug in the regexp used to replace the git url by SOURCE_MIRROR_URL.
paulg has quit [Ping timeout: 256 seconds]
<qschulz>
actia: would be great if you could reproduce on the master branch to check if we're still affected or not
<actia>
qschulz: I'm not sure my project can be switched from thud to master. I think that some syntaxe have changed.
<RP>
zeddii: FWIW it wouldn't be hard to pause task dispatching. paulg disappeared...
<JaMa>
zeddii: unfortunately it's not just builders with 16G ram, with 32c 64t 3970X threadripper I used to be fine with 128G ram, now 2G per thread too often isn't enough and OOMK gets violent
<qschulz>
actia: you don't need to switch the whol;e project from thud to master, just need newer poky with only PREMIRRORS configured as you did on thud
<RP>
JaMa: was that with the limiting code we ended up adding to core?
<actia>
Ok, but I encounter the issue with the git url of my local gitlab server, so I need to port at least my recipe using this url.
<JaMa>
zeddii: as simple work around I'm changing PARALLEL_MAKE for 2 hungriest recipes in my builds PARALLEL_MAKE:pn-qtwebengine = "-j 40"
<JaMa>
PARALLEL_MAKE:pn-webruntime = "-j 40"
<JaMa>
RP: yes with limiter as I have only 64 threads anyway
Guest22 has quit [Quit: Client closed]
<RP>
JaMa: right, yes. I wonder if the limit should be a bit lower? :/
lucaceresoli_ has joined #yocto
<actia>
qschulz: I will try tomorrow, I will let you know if the issue is still on the master branch
<JaMa>
RP: yeah, but limitting all the tasks globally might hurt overall build time as well, e.g. with qtwebengine/webruntime the memory usage peak is only terrible only for few minutes
<JaMa>
RP: swap is terrible, but to keep OOMK quiet for these few minutes is possibly reasonable work around as well
lucaceresoli has quit [Ping timeout: 260 seconds]
<JaMa>
assuming the PC is used only for non-interactive OE builds during that time (running chrome browser is usually first victim of OOMK which together with stuttering mouse movement makes such workstation a bit annoying to use during the peak) :)
<kanavin>
RP: technically correct is the best kind of correct :)
<kanavin>
RP: I was thinking that when fetching from git, a 'tag' parameter in SRC_URI would be beneficial. the fetcher would then verify that the commit id resolves to the tag, which prevents supply chain attacks, or honest mistakes.
<kanavin>
right now, a version update only updates SRCREV and we have to trust that blindly more or less
<kanavin>
it could look like 'tag=v${PV}' or similar according to upstream format
<kanavin>
just doing the 'RP smoke check' for the idea, in case it's not viable :)
mcfrisk has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
kevinrowland has quit [Quit: Client closed]
<Ch^W_>
Is the failure to pull an updated git clone source bundle from the PREMIRRORS location a known bug?
dave has joined #yocto
dave is now known as aclaws
ecdhe_ has quit [Ping timeout: 252 seconds]
florian_kc has joined #yocto
florian_kc has quit [Ping timeout: 240 seconds]
kevinrowland has joined #yocto
<Saur[m]>
RP: I have pushed updated versions of my Knotty improvements to poky-contrib (branch: pkj/knotty-improvements) (since we still can't read/send work mail from home). I've removed the last patch. Instead the second patch now solves the problem with the width of the progress bar, and the addition of a progress bar for the setscene tasks (which I believe _is_ an improvement to the Knotty UI) is added as an optional third patch.
rob_w has quit [Quit: Leaving]
cb5r has quit [Ping timeout: 272 seconds]
cb5r has joined #yocto
camus has quit [Remote host closed the connection]
camus has joined #yocto
lucaceresoli_ has quit [Quit: Leaving]
<khem>
I think we need to sort virtual/libgl meaning and virtual/mesa should perhaps be removed
<khem>
perhaps we only should depend on virtual/egl and then let platform figure out if they use GLES or GL or OpenVG implementations
<fray>
There are libraries that replace mesa.. like the mali stuff..
<fray>
there are libraries that just provide libgl (or libegl)
<fray>
it's a real mess..
<fray>
For instance chrome uses virtual/ligl (this is from memory, so might not be exactly correct). Which essentially causes it to link to mesa.. but when I enable mali400 support.. it has to instead link to the mali400 version.. so it's not runtime compatible with mesa, only compile time..
<fray>
so I end up with two versions of chrome.. a mesa version and a mali400 version
camus has quit [Ping timeout: 256 seconds]
camus has joined #yocto
<khem>
applications perhaps can just ask for lib/egl
<khem>
if an app insists on needing libgl then its stepping down the abstaction and we should have a way to tell that this platform does not implement GL
<khem>
trying to let mesa-gl provide s/w rendering is iffy I am not sure if it has ever worked
<fray>
I've also had to go through (on my own system) and add bbappends to anything linking to mesa.. so if mali400 is enabled it now becomes PACAKGE_ARCH machine specific..
florian_kc has joined #yocto
<smurray>
fray: iirc, both Renesas and Qualcomm also have their own libgl replacements
<fray>
Ya, it's not unusual for us.. and it's a mess
<khem>
thats the point, some folks implement GL and GLES and some stick to just GLES
<khem>
but they all implement EGL
GNUmoon has quit [Ping timeout: 240 seconds]
cb5r has quit [Quit: cb5r]
<fray>
but most things, like Chrome, actually require a mesa like interface.. (which complicates this)
florian_kc has quit [Ping timeout: 250 seconds]
jmiehe has joined #yocto
dkl has quit [Quit: %quit%]
leon-anavi has quit [Remote host closed the connection]
GNUmoon has joined #yocto
dkl has joined #yocto
<RP>
Saur[m]: we're definitely not doing the two progress bars. If I thought the discussion were going this way I'd have refused to split the line at all
<RP>
kanavin: I think bitbake will verify tags if specified as it annoys some people
Bardon has quit [Ping timeout: 256 seconds]
Bardon has joined #yocto
alejandrohs has quit [Ping timeout: 240 seconds]
alejandrohs has joined #yocto
<RP>
Saur[m]: we'd better stick to list review as the patch in that branch looks a bit rushed (e.g. the py.my file)
<Saur[m]>
RP: Of course. This was more of a heads up since I can't send the patches until some time tomorrow. (And I have removed that .py.my file now.)
<RP>
Saur[m]: you change the behaviour for quiet too?
<RP>
Saur[m]: there is just too much changing in that patch to make me feel confident in it
<Saur[m]>
Well, I thought the idea with the quiet mode was that it does not output the list of currently running tasks. Thus it seemed more logical that the output of the setscene/real task output was the same.
<Saur[m]>
Especially I could not set the logic in the quiet mode not having the output of the number of currently running tasks. I found that very odd.
<Saur[m]>
see*
<RP>
Saur[m]: The commit message doesn't mention this at all and you're just guessing about what quiet mode does. This just means I now have to read your patches very carefully :(
<RP>
Saur[m]: if the quiet behaviour is incorrect, it is a separate issue
<Saur[m]>
I'm not saying it is incorrect, I just found it odd that it was lacking the currently running tasks in its output. Also, changing the output of the quiet mode probably made more sense when I added the progress bar for the setscene tasks.
Minvera has quit [Remote host closed the connection]
neverpanic has quit [Quit: reboot]
neverpanic has joined #yocto
florian_kc has joined #yocto
<Saur[m]>
@rp:
<Saur[m]>
RP: Ok, pushed an updated branch that makes no changes at all to the output except corrects the length of the progress bar.
Etheryon has joined #yocto
Etheryon has quit [Client Quit]
mvlad has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
camus1 has joined #yocto
camus has quit [Read error: Connection reset by peer]