sakoman has quit [Read error: Connection reset by peer]
otavio has joined #yocto
sakoman has joined #yocto
halstead has quit [Quit: Leaving]
halstead has joined #yocto
<paulg>
zeddiii, RP LTP test set (on an old LTP) on vanilla 5.10.42 defconfig on real hardware doesn't seem to want to splat.
<paulg>
building sato at the same time ; had to restart that since I got my *favourite* error...
<paulg>
ERROR: pseudo-native-1.9.0+gitAUTOINC+ee24ebec9e-r0 do_populate_sysroot: If the above message is too much, the simpler version is you're advised to wipe out tmp and rebuild (reusing sstate is fine). That will likely fix things in most (but not all) cases.
<paulg>
I just LOVE the TL;DR nuke-everything message. Makes me so full of glee.
otavio has quit [Ping timeout: 268 seconds]
otavio has joined #yocto
rber|res has joined #yocto
RobertBerger has quit [Ping timeout: 264 seconds]
<paulg>
[ 8239.927474] cgroup: Unknown subsys name 'memory'
<paulg>
defconfig doesn't enable that ; wonder if that is related....
goliath has quit [Quit: SIGSEGV]
sakoman has quit [Quit: Leaving.]
mranostaj has quit [Ping timeout: 265 seconds]
mranostaj has joined #yocto
* paulg
shoulda asked RP how much mem he was giving qemu
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #yocto
halstead_ has joined #yocto
halstead has quit [Ping timeout: 245 seconds]
halstead__ has joined #yocto
halstead__ is now known as halstead
halstead_ has quit [Ping timeout: 264 seconds]
khem has quit [Remote host closed the connection]
Andrei[m] has quit [Remote host closed the connection]
Emantor[m] has quit [Read error: Connection reset by peer]
ejoerns[m] has quit [Read error: Connection reset by peer]
jordemort has quit [Remote host closed the connection]
barath has quit [Write error: Connection reset by peer]
cody has quit [Read error: Connection reset by peer]
shoragan[m] has quit [Write error: Connection reset by peer]
kayterina[m] has quit [Remote host closed the connection]
alex88[m] has quit [Remote host closed the connection]
Pierre-jeanTexie has quit [Remote host closed the connection]
janvermaete[m] has quit [Remote host closed the connection]
Jari[m] has quit [Remote host closed the connection]
shoragan|m has quit [Remote host closed the connection]
AlessandroTaglia has quit [Remote host closed the connection]
Spectrejan[m] has quit [Remote host closed the connection]
ndec[m] has quit [Read error: Connection reset by peer]
dwagenk has quit [Remote host closed the connection]
Saur[m] has quit [Read error: Connection reset by peer]
asus_986_gpu[m] has quit [Remote host closed the connection]
Andrei[m] has joined #yocto
kayterina[m] has joined #yocto
jordemort has joined #yocto
Jari[m] has joined #yocto
janvermaete[m] has joined #yocto
Saur[m] has joined #yocto
Emantor[m] has joined #yocto
ejoerns[m] has joined #yocto
ndec[m] has joined #yocto
Pierre-jeanTexie has joined #yocto
khem has joined #yocto
cody has joined #yocto
shoragan[m] has joined #yocto
barath has joined #yocto
shoragan|m has joined #yocto
Spectrejan[m] has joined #yocto
alex88[m] has joined #yocto
AlessandroTaglia has joined #yocto
asus_986_gpu[m] has joined #yocto
dwagenk has joined #yocto
davidinux has joined #yocto
FO2 has joined #yocto
tlwoerner_ has joined #yocto
tlwoerner has quit [Ping timeout: 272 seconds]
FO3 has quit [Ping timeout: 272 seconds]
Guest38 has joined #yocto
Guest38 has quit [Quit: Client closed]
chrfle_ has joined #yocto
rob_w has joined #yocto
rber|res has quit [Ping timeout: 264 seconds]
rber|res has joined #yocto
ant_ has quit [Quit: Leaving]
hpsy has joined #yocto
leon-anavi has joined #yocto
mckoan|away is now known as mckoan
zyga-mbp has joined #yocto
ilunev has joined #yocto
tnovotny has joined #yocto
goliath has joined #yocto
bps has quit [Remote host closed the connection]
ant_ has joined #yocto
rber|res has quit [Quit: Leaving]
BCMM has joined #yocto
ilunev has quit [Ping timeout: 272 seconds]
manuel1985 has joined #yocto
<RP>
zeddiii: paulg: 512M fwiw and I've found the issue reproduces with 5.10.20. older 5.10 segfaults during build :/
michael has joined #yocto
<RP>
5.10.17 is the first which builds, I'll test that next
ilunev has joined #yocto
<RP>
and present in 5.10.17.
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zyga-mbp has joined #yocto
<zeddiii>
ech. all the way back to .17 ... do 'we' think it is both something that showed up in 5.10 and some userspace interaction that was introduced ?
kpo_ has quit [Read error: Connection reset by peer]
kpo_ has joined #yocto
tlwoerner_ has quit [Quit: Leaving]
tlwoerner has joined #yocto
michael has quit [Quit: Leaving]
<RP>
zeddiii: I don't know what to make of it. The issue has to be toolchain, qemu or kernel
<RP>
zeddiii: I have 5.10.5 building now so will see how that looks
* RP
stepped away for food etc
<zeddiii>
I start to get my secondary test machine ready last night, but I have to remove tmp, the build blew up first thing and I had already walked away.
<zeddiii>
a rookie mistake
<RP>
zeddiii: reproduced with 5.10.5
<RP>
zeddiii: question is what next. keep hitting 5.10? try 5.4? 5.12?
<RP>
is it an unknown kernel issue? or a qemu bug? or toolchain?
* paulg
thinks ! kernel
* paulg
thinks coffee is needed
<v0n>
Is there a variable pointing to a tarball of a package files? (prior to being turned into a .ipk for example)
<v0n>
Humm maybe it's cleaner to add a custom do_archive task in the recipe.
<smurray>
there's the archiver.bbclass stuff if it's source archiving for compliance you're looking for
<v0n>
smurray: yes, I have a package for definition files, but somehow a customer wants a tarball of the said source instead of installing them into the image.
<v0n>
JPEW: cp -r --no-preserve=ownership, thanks a lot!
<smurray>
heh, was just about to mention the file ownership issue, but the docs explain it better
<v0n>
btw --no-preverse doesn't exist
* v0n
needs coffee
Ileana has joined #yocto
patrick_r has joined #yocto
<patrick_r>
hello
<patrick_r>
one question about mariadb, I need to include libmysqlclient as my C program is using it. I added mariadb fine but despite the fact that bitbake says "mariadb RPROVIDES libmysqlclient-dev" I cannot add it as a DEPENDS to my recipe. that package exists in mariadb/<version>/deploy/<arm7 ...>/ build directory and includes the files I need to compile
<patrick_r>
such as mysql.h how do I add that package so that my program compiles?
<v0n>
hum, build/tmp/deploy/sources/ is still empty
<RP>
paulg, zeddiii: Also reproduced with 5.13-rc5
<paulg>
sure as hell is starting to smell more and more like "not kernel"
<paulg>
qemu/toolchain... ???
<RP>
paulg: agreed, question is what and how to find it
<smurray>
patrick_r: are you adding mariadb to DEPENDS?
<patrick_r>
@smurray: yes
<paulg>
and what am I missing that I can't trigger it here when trying to replicate your test? :-(
<ant_>
RP guerrilla building linux-next: next-20210610 is your last chanche :)
<patrick_r>
smurray: but the compilation fails as cannot find mysql.h
<RP>
paulg: FWIW this on an Ubuntu 20.04.02 LTS host
<smurray>
patrick_r: hrm, the recipe packaging seems to explicitly create libmysqlclient-dev, so perhaps try adding libmysqlclient (no -dev) to DEPENDS
<v0n>
smurray: build/tmp/deploy/sources still empty even though I added: inherit archiver; ARCHIVER_MODE[src] = "original" and COPYLEFT_LICENSE_INCLUDE = "${LICENSE}" to the recipe
<patrick_r>
smurray: still cannot find mysql.h
<smurray>
patrick_r: what's being used for the #include, think it'd need to be mysql/mysql.h?
<patrick_r>
smurray: mysql.h is inside the libmysqlclient-dev rpm found in the deploy directory of the build of mariadb
<smurray>
patrick_r: where it needs to be is in the recipe-sysroot/usr/include/... in the WORKDIR of whatever it is you're trying to build
<smurray>
patrick_r: perhaps check recipe-sysroot/sysroot-providers to see if mariadb / libmysqlclient are making it in
<smurray>
v0n: I've never tried tinkering with the filtering like that, perhaps check with 'bitbake -e' to see if the COPYLEFT_* variables are getting set to what you expect
<v0n>
smurray: inherit archiver from within the recipe itself should work, right?
<smurray>
v0n: in theory, not sure if anyone does it that way
<smurray>
v0n: it's outside of my limited use of archiver.bbclass, I've always used it for whole images. Others here might have a better idea
<v0n>
with INHERIT += "archiver", will every packages be archived? I don't want to slow the build for one package
<smurray>
the default is all target packages, so yes, it'd be less than ideal if you just want a single one
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<chrfle_>
anyone got any clue as to why adding vm.min_free_kbytes=4096 into /etc/sysctl.d/ has no effect?
<smurray>
v0n: if you're just setting COPYLEFT_LICENSE_INCLUDE, you may need to also set COPYLEFT_LICENSE_EXCLUDE = ""
sakoman has joined #yocto
zyga-mbp has joined #yocto
yocton has joined #yocto
ffer has joined #yocto
<ffer>
Hi All, I'm trying to get core-image-minimal running on a Intel NUC, with NFS root. Layers used: meta-intel and poky. Already included initramfs-module-nfsrootfs to INITRAMFS_SCRIPTS, so I can see it trying to mount the root NFS during boot. The problem: the network is not configured. Changed nfsrootfs initscript to show the interfaces: only lo and sit0@none available. My question is where I can look into to
<sgw>
RP: a quick workaround for the qmp issue is to create a second qmp listening port with: '-qmp unix:./%s,server,' % (qmp_file2) this one does not wait for a connection to continue like the primary one does.
chrfle_ has quit [Ping timeout: 244 seconds]
<RP>
sgw: handy to know, we could do that by default so we have something ready if needed?
<RP>
zeddiii, paulg: FWIW we get the bug with qemu 5.2.0 as well as 6.0.0
<sgw>
Yup, I will send a patch, do we want to try and have a better name or print it out?
<v0n>
I have SSTATE_DIR outside of TOPDIR, but after removing build/ linux do_compile runs again. Is it expected?
<RP>
sgw: As long as its printed somewhere I think we're ok
kpo_ has quit [Read error: Connection reset by peer]
kpo_ has joined #yocto
roussinm1 has quit [Quit: WeeChat 3.1-dev]
hpsy has quit [Ping timeout: 272 seconds]
sakoman has quit [Ping timeout: 264 seconds]
<RP>
zeddiii, paulg: For completeness, 5.4.123 also breaks
<paulg>
That pretty much seals it as far as giving aufs (and the kernel itself) a get-out-of-jail-free card.
yocton has quit [Ping timeout: 250 seconds]
<RP>
paulg: yes. Next up, gcc 11.1.1 -> 11.1.0
<paulg>
I want this to be found but at the same time I don't want it to be toolchain. :-/
roussinm has joined #yocto
<RP>
paulg: unfortunately it is the next logical thing to test :/
<paulg>
maybe try waving a rubber chicken over your head 3x while chanting ?
<RP>
khem: this ltp test corrupting the qemu VM with kernel crashes
<khem>
RP: that patch only affects Ada I guess it wont matter here
<RP>
khem: ah, right. I missed that bit
<khem>
are these new regressions ?
<RP>
khem: I can't tell :(
CosmicPenguin_ is now known as CosmicPenguin
ant_ has joined #yocto
zyga-mbp has joined #yocto
zyga-mbp has quit [Client Quit]
tnovotny has quit [Quit: Leaving]
<RP>
khem: I mailed details to the oe-core list so save me repeating myself and put the info in one place
* RP
pulled away for a bit
nerdboy has quit [Ping timeout: 244 seconds]
nerdboy has joined #yocto
dev1990 has joined #yocto
hpsy has joined #yocto
wesm has quit [Ping timeout: 264 seconds]
prabhakarlad has quit [Quit: Client closed]
wesm has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
prabhakarlad has joined #yocto
otavio has quit [Ping timeout: 272 seconds]
<jbronder>
I'm trying to test out a patch for the issue I had with multiconfig and the esdk yesterday in dunfell (I'll build it in master later). With oe-core dunfell and bitbake 1.46.8 the esdk builds fine but installing fails with layers/openembedded-core/meta/recipes-devtools/pseudo/pseudo_git.bb:do_fetch) failed with exit code 'setscene whitelist'
<jbronder>
Is the esdk expected to work with core-image-sato?
sakoman has joined #yocto
davidinux has quit [Ping timeout: 245 seconds]
davidinux has joined #yocto
hpsy has quit [Ping timeout: 245 seconds]
jbronder is now known as jsbronder
<Ch^W>
FYI... we upgraded from thud to hardknott, and now we see systemd state "leaking" across the initrd barrier. I poked #systemd about this.
<Ch^W>
Specifically we have a filesystem mount unit that is briefly started and stopped in initrd (some pre-boot setup is done in our distro). The "stopped" state is now occasionally seen after switch root.
<Ch^W>
We caught it because we have a dependency on that mount unit in our main runtime. Since it shows up as stopped, the runtime startup breaks.
Ileana has quit [Ping timeout: 250 seconds]
fitzsim has left #yocto [ERC (IRC client for Emacs 28.0.50)]
fitzsim has joined #yocto
vmeson has quit [Ping timeout: 252 seconds]
Guest38 has joined #yocto
vmeson has joined #yocto
zyga-mbp has joined #yocto
<khem>
jsbronder: eSDK is usually tested with poky distro, and there are some distro bits that can affect when building for nodistro/oe-core alone
<khem>
Ch^W: what init system are you running inside initramfs ?
<jsbronder>
khem: ok thanks, I'll start looking in there for what else I need to set I guess.
<Ch^W>
khem: systemd
Vonter has quit [Ping timeout: 252 seconds]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Guest38 has quit [Quit: Client closed]
<RP>
zeddiii, paulg, vmeson: trying with gcc 10.3 now
<paulg>
fun. stolen from dunfell or similar I presume?
<paulg>
It'd probably take me the better part of the day to figure out how to do that.
dtometzki has joined #yocto
<Emantor>
Hm, i have a recipe requiring imagemagick-native, the makefile wants "convert" but bitbake -c devshell shows that only "convert.im7" exists, how do I tell the system to set the ALTERNATIVE_LINKs when building as -native?
<Emantor>
(I'll be off now, reading backlog tomorrow)
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<paulg>
so, for those following along, it seems the mount related LTP hang doesn't happen when using qemu w/o KVM support (or AFAICT, on bare metal)
<RP>
vmeson: so you and paulg can now reproduce and I'm not imagining this :)
<RP>
paulg: for reference which host OS is that on? (distro version and kernel version)
zyga-mbp has joined #yocto
<paulg>
I shoulda sync'd with vmeson and we coulda jerked your chain for a couple more hours. B-)
<paulg>
---------
<paulg>
testimage$cat /etc/lsb-release
<paulg>
DISTRIB_ID=Ubuntu
<paulg>
DISTRIB_DESCRIPTION="Ubuntu 18.04.3 LTS"
<paulg>
DISTRIB_CODENAME=bionic
<paulg>
DISTRIB_RELEASE=18.04
<paulg>
testimage$cat /proc/version
<paulg>
Linux version 5.4.0-72-generic (buildd@lgw01-amd64-021) (gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)) #80~18.04.1-Ubuntu SMP Mon Apr 12 23:26:25 UTC 2021
<paulg>
testimage$
<paulg>
------------
<paulg>
same machine vmeson was using AFAIK
<vmeson>
paulg: close but not identical software (ubu-18.04.3) and I'm using the 192 core monster.
<vmeson>
oops, you're on 18.04.3 too.
<paulg>
and on the same mega core monster. Pay attention. :-P
zyga-mbp has quit [Client Quit]
<paulg>
going to try and repatriate my testing to a "local" machine next ; one I hve root on.
<vmeson>
I've seen it now on ubu-21.04 with a diferent machine as well.
<paulg>
I'm not quite yet sure how to best make use of the fact that KVM enabled testing is required...
<vmeson>
The test on ubu-21.04 hangs or at least takes > 24 mintues
<RP>
vmeson: it can hang, the kernel is basically fried after it breaks
<vmeson>
Oh, so does the other system.
<RP>
so far this is all with 5.4 host kernels?
<vmeson>
No, the second system I used (ubu-21.04 has: Linux yow-rmacleod-lx3 5.11.0-18-generic #19-Ubuntu SMP Fri May 7 14:22:03 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux )
<RP>
I just reproduced with gcc 10.3 too
<RP>
so it occurs with kernels 5.4.123, 5.10.1-5.10.42, 5.13-rc5 and gcc 11.1.0, 11.1.1 and 10.3 and qemu 5.2.0 and 6.0.0
<RP>
that is a mess :/
* RP
wonders what next
<vmeson>
RP: something we've changed recently has unearthed this bug. Do you know when it started or should I dig through the AB logs?
<RP>
vmeson: The trouble is this is intermittent and we've seen qemu crashes and odd behaviour for a while
<RP>
vmeson: so I'm not really sure when this started happening or how long it has been around for
<vmeson>
Do we know if it happens on hardknott?
<RP>
vmeson: with those versions I'd say yes
<RP>
JPEW: hmm :/
<paulg>
is KVM enabled the "cause" or just a catalyst? Who knows...
<JPEW>
RP: Ya, not sure. This is bascially what we do interally for all our python stuff... I don't know if it is awesome or awful
* vmeson
cherry-picks the ltp commit from rpurdie/t222 back to gatesgarth, starts a build and walks towards the beer fridge.
<JPEW>
Although, this has the advantage that a script is sourced to put bbpython in PATH before running bitbake, it gets uglyier if you can't do that... I have a lot of people who seem to that that's an awful way to do things :(
<RP>
JPEW: I haven't quite made up my mind. I do worry a lot about relying on pip though :/
<RP>
paulg: Hard to know what/where to blame for this :/
<JPEW>
Ya... there are ways to package up a venv (we could even make a nice command to do it) for those that are airgapped/no-network/reproducible
<RP>
JPEW: traditionally, it is called buildtools-tarball :)
<RP>
JPEW: that script will also really upset the people who use readonly checkouts of bitbake/metadata
<RP>
yes, they do exist
<RP>
they email me now and again
<RP>
paulg, zeddiii: Is there extra kernel debugging we could turn on which might detect corruption earlier?
<paulg>
not sure...
<paulg>
I was about to ask vmeson for copies of his testimage qemu boot logs ; I'd like a larger sample set than the one I've created just 1h ago to look for patterns in the 1st oops/null-deref
<RP>
paulg: I have a load...
<paulg>
make that two -- looks like I got it again ; two "ok:" and then fail.