<RP>
JaMa: Status is that we won't build 4.0.3 until we resolve this and the kernel reproducibility issue
<RP>
JaMa: I'd much rather go with an upstream fix and your patch earlier gives me hope that might be close?
<RP>
JaMa: I think if we know it will be addressed upstream, we could merge the revert in the meantime
florian_kc has joined #yocto
<RP>
kanavin: we have a looming problem with virgl and the 5.19 kernel btw, see my reply to Bruce
<RP>
kanavin: I'm pretty sure he'd welcome any tips on what "failed to set mode: Invalid argument" might mean
<JaMa>
RP: there 2 issues with DEBUG_BUILD, one already in kirkstone for which there is no fix upstream (not even update) and then new one introduced in 2.36 for which I've sent a fix from upstream (which will be updated and merged hopefully soon)
<kanavin>
RP: I suspect a drm syscall into the kernel is failing where it was not failing before
<kanavin>
RP: running kmscube under strace would at least reveal which one
<kanavin>
RP: I can try that if there is a branch
<kanavin>
I'll write a reply
<JaMa>
RP: I was hopping for the 2 patches for 2.35 (DEBUG_BUILD revert from me and stable update from Sundeep) to be merged in master before 2.36 upgrade and then both cherry-picked to kirkstone
<RP>
kanavin: I removed the problem pieces from master-next but it was from Bruce's last series on list
<JaMa>
it will cause small conflict in 2.36 upgrade (patch in SRC_URI and SRCREV in glibc-version.inc), I've already rebased it in my jansa/master branch and can send it if it helps
<RP>
ptsneves: libsdl will be qemu, xterm was probably menuconfig
<ptsneves>
ok, thanks :)
<kanavin>
ptsneves, you can skip libsdl if you only want console output from qemu and not anything graphical
<ptsneves>
what is the need for qemu? For default testimage?
<kanavin>
I also think we're building our own sdl nowadays, so the inclusion of sdl is probably not accurate
<kanavin>
ptsneves, if you want to run images directly on the build host without flashing them to target hardware
<kanavin>
ptsneves, also, that's the environment for all standard tests
<kanavin>
selftest, and testimage
<ptsneves>
@kanavin ok thanks. For non oe-devel work i never saw it in use. Thanks
<kanavin>
ptsneves, qemu also helps if you can't give every developer the actual board
<ptsneves>
would this require extra machine conf for the bootloader differences?
<kanavin>
ptsneves, typically you use a qemu-specific MACHINE
<kanavin>
e.g. qemux86-64
<kanavin>
that machine does not use a bootloader at all, it simply gives the kernel and the rootfs directly to qemu as command line parameters
<ptsneves>
@kanavin. Ah sounds quite good.
<ptsneves>
In the past i tried to use it, but due the embedded nature of the stuff i worked with there was always quite a lot of maintenance required for the qemu version. Like applications that assumed i2c, gpio or security chips. I once even coded a pwm mock kernel module for qemu...
<kanavin>
ptsneves, yeah, you probably need to find out if qemu can emulate these, or if the kernel has 'mock' versions that aren't backed by actual hardware
<ptsneves>
@kanavin is there any easy way to find mock drivers? I did not know this was usual
<kanavin>
ptsneves, I do not know really, it's just always useful to have virtual hardware when the real one is not ready or available
<rfried>
Hi. I'm trying to add python3-pyelftools to SDK,
<rfried>
I added "nativesdk" to BBCLASSEXTEND and added "nativesdk-python3-pyelftools" to TOOLCHAIN_HOST_TASK.
<rfried>
This results in the error: package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target is intended for a different architecture.
* JaMa
just noticed that his TERMCMD* variables in local.conf don't work since 2011 :)
<ptsneves>
JaMa: so do i understand correctly that xterm should not be a requirement anymore?
<ptsneves>
and the doc should be corrected?
fennec has joined #yocto
<JaMa>
it's not the default anymore, I haven't tried how 'auto' works nowadays (I was always using screen, because of head-less builders/containers/chroots)
<JaMa>
also it's not enforced by sanity check I believe, the docs could be improved to list only the real essentials (enforced by sanity) and then recommended packages (with some explanation where they might be needed)
<Guest40>
Hope we are all well. I have raspberry pi cm4 and that has two ethernet ports one is the onboard and the other is powered using the RTL8153B. When booting the image the ethernet port does not come up automatically and i have to manually type ifconfig eth1
<Guest40>
I am also trying to select the correct driver when compiling my image i have to use the command "IMAGE_INSTALL:append = "linux-firmware"
<Guest40>
in my local.conf
<Guest40>
this loads all the drivers but I unable to only select the relevant driver. Can anyone over any advice on this
<Guest40>
When using "linux-fimrware" this installs all the driver from the recipe but all I want to use is the RTL8153 driver
<Guest40>
I have tried other variations but to no sucess. Any guidance would be appreciated
fennec has joined #yocto
agupta1 has quit [Ping timeout: 245 seconds]
paowz_ has quit [Ping timeout: 244 seconds]
agupta1 has joined #yocto
<qschulz>
Guest40: do you know the name of the file you need in /lib/firmware (I assume this is the path)
<Guest40>
yeh it is RTL8153B
<Guest40>
thanks for responding
<Guest40>
yeh thats the path when I compile using "linux-firmware" that is where the fw is located
<Guest40>
I have tried setting it up as a module in the virtual menuconfig and trying adding the kernel but still did not work
<Guest40>
I also checked the linux-firmware recipe but it doesnt have rtl8153
<qschulz>
Guest40: when you add linux-firmware package to your image, does your second ethernet interface work?
<Guest40>
yep but it till does not come up automatically
<Guest40>
still i have bring up the interface manually using ifconfig eth1
nemik has quit [Ping timeout: 268 seconds]
ptsneves has joined #yocto
Guest263 has quit [Ping timeout: 240 seconds]
<qschulz>
Guest40: so, you need one of the files installed by linux-firmare package, do you know exactly which one?
paowz_ has joined #yocto
<qschulz>
I'm asking because once you know whcih file is needed, you can find which package installs it
<qschulz>
because linux-firmware package is a special package pulling in all linux-firmware-something packages
<Guest40>
ok cool the driver I need is rtl8153b-2.fw
<qschulz>
and you only want one obviously and not the whole thing, way too big, and uselles
<qschulz>
Guest40: ok, run oe-pkgdata-util find-path '*rtl8153b-2.fw*' in your terminal (on your host, where you built your yocto image)
nemik has joined #yocto
<Guest40>
ok cool give me 5 min
<Guest40>
just booting up the server now
kroon has quit [Quit: Leaving]
<kanavin>
zeddii, if a system call returns -1, what's the best way to trace why that happens?
<kanavin>
given core-image-minimal in qemu
<zeddii>
minimal is so devoid of useful tools, I always end up just looking at the source. otherwise, I add ftrace/perf and read the docs again to figure out how the heck to run them.
<zeddii>
and if anyone else messaged me, I missed it .. since I had a power failure and didn't realize my IRC bouncer didn't reconnect,
xmn has joined #yocto
jclsn has quit [Quit: WeeChat 3.5]
sakoman has joined #yocto
<Guest40>
qschulz ok tried running it but command not found on the oe-pkgdata-util
<qschulz>
Guest40: in a terminal where you can use bitbake?
<Guest40>
qschulz sorted forgot to initialise build enviroment
<qschulz>
you need a bbappend with those changes but adapted to yours
rob_w has quit [Quit: Leaving]
<kanavin>
zeddii, that actually helped - the source code for the syscall has DRM_DEBUG_KMS(diagnostic_message) all over it, so once enabled it prints useful stuff to dmesg
<kanavin>
(enabled via drm.debug=0x04 cmdline)
<kanavin>
I'd never know that without the source :)
<Guest40>
qschulz excellent cool will give it a go. Would you happen to know why the ethernet device does not come up automatically ?
<wkawka>
Hi, how can I check all dependency tree for a recipe (packagegroup to be precised)
<qschulz>
wkawka: bitbake -g and then use your favorite text editor to read the dot files
<qschulz>
Guest40: I would assume it's the default behavior for interfaces
ptsneves has quit [Quit: ptsneves]
<wkawka>
Ok, thank you
ptsneves has joined #yocto
<qschulz>
Guest40: and that if you have dhcp running at boot it's probably running only on eth0 by default?
<qschulz>
and that would put the eth0 interface up for you "transparently"
<Guest40>
qschulz ok makes sense
thomasd13 has quit [Ping timeout: 252 seconds]
agupta1_ has joined #yocto
Guest40 has quit [Quit: Client closed]
Guest2237 has joined #yocto
agupta1 has quit [Ping timeout: 255 seconds]
frieder has quit [Ping timeout: 245 seconds]
<Guest2237>
Hello, sorry, but I have a problem again. I'm using boost in my project an that is working good so far, but now I need libboost_fiber.a, it is build (find could find it) but it is not in the sysroot folder. Other boost libs are there. Any idea whats wrong?
argonautx has quit [Remote host closed the connection]
<fennec>
I tried psplash on my image butdespite various systemd tricks like disabling the tty1's getty, there is still a moment where the console is visible before weston starts. What can I try next?
<wkawka>
Hi, how is it possible that something is in RDEPENDS (I checked it from -e log), but it does not appear in -g log?
nemik has joined #yocto
<qschulz>
wkawka: which dot file did you look at?
<wkawka>
I looked at dot file of packagegroup and image, in both of them there is nothing about it
Guest263 has joined #yocto
<Guest2237>
qschulz Thanks, that could be the solution. (Why did't google found that...)
<wkawka>
and -e log file was from packagegroup
<qschulz>
Guest2237: if that works for you, can you answer to this mail saying you tested it? (Tested-by: Firstname + name <email-address>)
<qschulz>
Guest2237: well.. it was from 8h ago, still very fresh :)
<qschulz>
wkawka: I assume it could be possible if the package whose RDEPENDS you're looking at is not part of the image somehow
<qschulz>
wkawka: could you tell us what you want to do and what's the issue you're encountering at the moment?
<ptsneves>
on almost latest poky i get "python3-markupsafe-native-2.1.1-r0 do_compile: 'python3 setup.py bdist_wheel ' execution failed." Did anybody ever have this issue?
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
<wkawka>
I'm working on updating building on new kernel version (kernel is done already) and moving it into kirkstone from hardknott. The problem is that xserver-xorg-extension-viv-autohdmi is not provided, and I'm trying to investigate from where it was provided before. There is no recipe in the old one, and I thought about dependency tree
<wkawka>
Kernel is doe now I'm upgrading target image to be precise
<wkawka>
done *
<wkawka>
besides, is there an option to edit messages here?
<qschulz>
wkawka: no :)
<qschulz>
power of IRC :)
goliath has quit [Quit: SIGSEGV]
florian_kc has joined #yocto
<qschulz>
if you're using our Matrix bridge you technically can, but it appears as a new message on the IRC channel
<RP>
JaMa, sakoman: I merged the glibc revert
<qschulz>
wkawka: the easy way otherwise is to remove the recipe/package and see what fails to build or install
<sakoman>
RP: thanks, I'll cherry-pick it into kirkstone. I still need a fix for the CC_HAS_ASM_GOTO kernel issue before we can do the 4.0.3 build, but it looks like abelloni is testing that
<RP>
sakoman: right, I thought it might help to at least move glibc forward
<sakoman>
RP: yes indeed! I'll get that tested in kirkstone
<wkawka>
I tried it, but there is a weird syntax like `bb.utils.contains('DISTRO_FEATURES', 'x11') etc
<wkawka>
And I got parse error then
<RP>
zeddii: I merged the initial bits of the kernel series and the 5.19 headers FWIW as those all seemed ok. We can work on the other bits
frieder has joined #yocto
<JaMa>
RP: thanks
<wkawka>
Ok i left space there only, and it is parsed, let's see what this will bring
<JaMa>
hmm wanted to test that syslinux glibc fix with musl and 'TCLIBC:qemux86-64 = "musl"' exploded spectacularly.. it created tmp-musl/hostools as well as tmp-glibc/(without-hosttools) and all tasks failed because of missing zstd (probably looking in wrong HOSTTOOLS directory), anyone seen madness like this?
<RP>
JaMa: I've never tried that but I can imagine it breaking
<JaMa>
I had it commented out in local.conf, so I think it used to work before
<JaMa>
without the :qemux86-64 override it seems to work
<RP>
JaMa: if you file a bug we can look into it at some point
* RP
has too many other issues atm :(
<JaMa>
I don't need this to work, I was just interested if it's known/expected and I don't want to add more work to you (or anyone else as there are more important issues to look into already)
<RP>
JaMa: I don't know if it should or shouldn't offhand. I'm kind of curious if we broke something
ptsneves has quit [Ping timeout: 268 seconds]
<JaMa>
I'll check if it works with kirkstone and fill a bug report if I find something interesting
<qschulz>
"didn't work for me", what happened and what were you exepecting to happen?
<qschulz>
error or build logs so we can help
goliath has joined #yocto
<JaMa>
RP: FYI: TCLIBC:qemux86-64 doesn't work even in dunfell (doesn't fail due to zstd, because dunfell doesn't need it, but still creates both tmp-glibc and tmp-musl), in kirkstone it fails the same as in master
<wkawka>
and as a result I got `The LIC_FILES_CHKSUM does not match for file://COPYING;md5=417b82f17fc02b88125331ed312f6f1b` `The new md5 checksum is 3c3fe2b904fd694f28d2f646ee16dddb`
<qschulz>
wkawka: well, you are saying that the same file has two different checksums
<qschulz>
that's not possible
<qschulz>
so I think you need to explain what you mean by "multiple License cheksums for different images"
prabhakarlad has quit [Quit: Client closed]
<wkawka>
Let's say I have 2 different images using different distros. Building image 1 the recipe has md5 sum 417..., but with the second it has 3c3...
<wkawka>
log of do_populate_lic says that
<wkawka>
maybe INSANE_SKIP will do?
Guest2237 has quit [Quit: Client closed]
davez has quit [Quit: Connection closed]
<qschulz>
I don't understand what you're trying to do
<qschulz>
in any case, LIC_FILES_CHKSUM:distro1 = "file://COPYING;md5=417b82f17fc02b88125331ed312f6f1b"
<qschulz>
and LIC_FILES_CHKSUM:distro2 = "file://COPYING;md5=3c3fe2b904fd694f28d2f646ee16dddb"
<qschulz>
should work
<qschulz>
but I don't really understand why would you need any of this
<qschulz>
if you have different versions of some piece of sw
<qschulz>
then just create different recipes
<qschulz>
and set PREFERRED_VERSION accordingly
wkawka has quit [Quit: Client closed]
florian_kc has quit [Ping timeout: 255 seconds]
dgriego has joined #yocto
prabhakarlad has joined #yocto
leon-anavi has quit [Quit: Leaving]
vladest has quit [Quit: vladest]
vladest has joined #yocto
vladest has quit [Ping timeout: 268 seconds]
brazuca has quit [Quit: Client closed]
jmiehe has joined #yocto
florian_kc has joined #yocto
aardo has quit [Read error: Connection reset by peer]
ardo has joined #yocto
Guest263 has quit [Ping timeout: 268 seconds]
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
amitk has quit [Ping timeout: 240 seconds]
Guest14 has joined #yocto
Guest14 is now known as brazuca
<JaMa>
anyone seeing libxml2, kbd, libidn2 build failure in dunfell after today's update? The changes don't seem to be related to this, so not sure why I've started to see them today (last docker image update also had only minor changes and shouldn't probably cause this)