<jwinarsk>
It looks like beaglebone-yocto master (mesa) + proprietary TI/PowerVR kernel driver (mesa branch) is the combo for Weston (x11 is broken).
sakoman has quit [Ping timeout: 272 seconds]
mvlad has joined #yocto
alessioigor has quit [Quit: alessioigor]
sakoman has joined #yocto
<RP>
jwinarsk: it seems a bit sad that it doesn't work without the binary driver :(
<jwinarsk>
rp: indeed. The open source PowerVR kernel driver is landing in 6.8 that plays with mesa 24 Vulkan. Which will use Vulkan + Zink for GL. The kernel driver will need open source contribution for the SGX530, as the upstream work is targeting the AXE-1-16M GPU.
tgamblin has quit [Quit: Leaving]
sakoman has quit [Ping timeout: 268 seconds]
noyez has quit [Quit: Client closed]
sakoman has joined #yocto
Guest68 has joined #yocto
<Guest68>
Problem with patching kernel. Used devtool extract to get at kernel source code
<Guest68>
then modified one file and git commit within devtool context then git format-patch against commit HEAD -1, copied resulting patch to recipes-kernel/files in bbappend recipe “files” folder then added the patch file to b append recipe . The patch is correctly formatted as a subsequent devtool extract followed by git am <patch file> succeeds …
<Guest68>
however bitbake virtual/kernel fails to apply the patch complaining that the file to be patched does not exist in the index
<mckoan>
Guest68: copy resulting patch to recipes-kernel/linux/files
rfuentess has quit [Remote host closed the connection]
<Guest68>
mckoan: The patch file is in my own layer in the files subdirectory of the bbappend recipe
<khem>
on master/scarthgap we are using 5.4.6 so perhaps we are not impacted maybe but when upgrading one should consider this
<khem>
oh hang on, I read it reverse, it seems all tarballs are impacted except v5.6.0 and v5.6.1 argh
<JaMa>
is it? gentoo recommends to downgrade (which I did), let me re-read it as well
noyez has joined #yocto
mckoan is now known as mckoan|away
Guest68 has joined #yocto
Guest68 has quit [Client Quit]
vladest has quit [Remote host closed the connection]
chep` has joined #yocto
chep has quit [Ping timeout: 260 seconds]
chep` is now known as chep
goliath has quit [Quit: SIGSEGV]
Guest68 has joined #yocto
Guest68 has quit [Client Quit]
<fullstop>
khem: maybe not, but the account which introduced the backdoor also released version 5.4.6.
<fullstop>
I would question every release from 5.4.0 on
<Xogium>
from another channel here
<Xogium>
19:37 < bill-auger> as the person responsible for it has been on the team for years, the maintainer is warning about all previous versions within the past few years - so debian reverted to a years old version
<Xogium>
either way this is highly suspicious and we have literally no way of finding out when that backdoor got started precisely
prabhakarlad has quit [Quit: Client closed]
<Xogium>
on the other hand there's a few more things to know about this
<fullstop>
every commit the account has made should be reviewed. What a loss.
<Xogium>
so far, the backdoor seems to, one: affect debian/fedora only, presumably ? two: only work if you have sshd which has sd_notify patch from debian which links against libsystemd thus introducing liblzma into the binary and finally: affects only x64 systems
<Xogium>
glibc
leon-anavi has quit [Quit: Leaving]
<Xogium>
I think someone more knowledgeable about security might find yet more things to uncover about the backdoor, but that's what we got to work with currently
noyez has quit [Quit: Client closed]
vladest has joined #yocto
<fullstop>
and nobody knows who they are, so that account will go dormant and spring up as a new identity in time.
alessioigor has joined #yocto
<Xogium>
indeed
<Xogium>
the maintainer might know
<Xogium>
but who's to say it isn't the maintainer ?
<fullstop>
Looking at the debian bug reports, it seems like they at least had puppet accounts urging pull requests to be accepted.
<Xogium>
hrm
<Xogium>
w
<Xogium>
oops
<Xogium>
:D
sev99 has quit [Quit: Client closed]
goliath has joined #yocto
sakoman has quit [Ping timeout: 255 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
sakoman has joined #yocto
Vonter has quit [Ping timeout: 256 seconds]
Vonter has joined #yocto
jpuhlman has quit [Ping timeout: 256 seconds]
jpuhlman has joined #yocto
jpuhlman has quit [Read error: Connection reset by peer]
jpuhlman has joined #yocto
Saur_Home85 has quit [Quit: Client closed]
Saur_Home85 has joined #yocto
* marex
reads backlog, sees version starting with 5. ... and knows what it is already, that is truly ugh
<Xogium>
I agree
<marex>
Xogium: I am reading the openwall announcement again
<marex>
Xogium: so I might just stick to ancient lzop for a bit
<Xogium>
ugh yeah. Who knows when this was started or anything
<Xogium>
I no longer trust any version of xz
Guest3 has joined #yocto
alperak has quit [Quit: Connection closed for inactivity]
<Guest3>
Problem with patching kernel. Used devtool extract to get at kernel source code
<Guest3>
then modified one file and git commit within devtool context then git format-patch against commit HEAD -1, copied resulting patch to recipes-kernel/files in bbappend recipe “files” folder then added the patch file to b append recipe . The patch is correctly formatted as a subsequent devtool extract followed by git am <patch file> succeeds …
<Guest3>
however bitbake virtual/kernel fails to apply the patch complaining that the file to be patched does not exist in the index
Guest3 has quit [Quit: Client closed]
ldywicki has joined #yocto
<ldywicki>
hello :)
<ldywicki>
good morning/evening to everyone, I come here as I got stuck with fairly basic (I suppose) issue related to dynamic linking of java binary. Similar binary works just fine with my desktop distro, but it fails with build. From this place I presume that binary is fine, issue comes from produced image. It boils down to libjli.so which is part of java
<ldywicki>
installation, for some reason during execution of bin/java my distro seeks it in /lib which leads to failure.
<ldywicki>
strace shows `openat(AT_FDCWD, "/usr/lib/libjli.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)`, which shouldn't be there, while ldd prints libjli.so => /usr/lib/amazon-corretto-11.0.22.7.1/bin/../lib/jli/libjli.so (0x0000007f81e60000)
<ldywicki>
[for java lovers, if any present, small note that this issue is not specific to amazon-corretto, it hits temurin too]
<ldywicki>
any sugestions on what's going on? :\
flom84 has joined #yocto
flom84 has quit [Remote host closed the connection]
<marex>
ldywicki: does it work if you start the application with LD_LIBRARY_PATH=/usr/lib/lib/ , or create a symlink from /usr/lib/lib/jli/libjli.so to /usr/lib/libjli.so ?
<ldywicki>
it does, I've plaed with LD_LIBRARY_PATH=/usr/lib/amazon-corretto-11.0.22.7.1/lib/jli and it went just fine
<ldywicki>
thing is, it looks to me like patching in wrong place as issue comes from other place
<marex>
I'm no java expert, so I dont know exactly what they do with shared libraries or how that is handled with those various JREs, sorry
<marex>
like if you should have maybe an "alternatives" for /usr/lib/libjli.so which points to the currently used JRE or something else
ajfriesen has joined #yocto
<ldywicki>
this library seem to be internal, so its not supposed to land in /usr/lib as it vary between JVM versions. Not that I plan to have multiple versions of it in image, but it will lead to pollution
<ldywicki>
so the `LD_LIBRARY_PATH=/usr/lib:/usr/lib/amazon-corretto-11.0.22.7.1/lib/jli bin/java -version` works ok
<ldywicki>
To be fair, I first thought that issue comes from temurin (another vendor of java binary), but it does not
<marex>
ldywicki: so, shouldn't there be some script which sets up the environment for each JRE before using it for whatever application ?
<marex>
(similar to the OE SDK setup script)
<ldywicki>
my host is working fine with similar java version, this linking issue strikes only in target image, I think OE SDK is on the host/build machiner
<ldywicki>
I thought so, but that I might be missing something in environment, but comparing ld.conf.d and environment build I have no extra entries with LD_LIBRARY_PATH
<ldywicki>
I've made also a spin of x86 and arm64 images (different java binaries), both happen to have same issue
<marex>
ldywicki: btw could it be there are more openat attemts for the libjli in the strace output, as the loader searches the library in various paths ?
<ldywicki>
I am completely lost why ldd shows proper (relative) path, but actual execution goes other way
jmd has quit [Remote host closed the connection]
<ldywicki>
I've updated gist with ldd and objdump output
<marex>
ldywicki: isnt the java executable doing something funny with the loader ?
<marex>
(I am only guessing, I might be completely wrong)
<ldywicki>
marex: to be honest, I don't know, I am just playing with more recent yocto as I had an image built with poky and look how yocto smells nowadays ;-) java is not that bad with linux, I think it rather plays with rules, uses pthread and other system utilities. It has a switchable part which bridge various OSes, but problem I (or rather we, thanks for
<ldywicki>
assistance!) face happens quite early. The libjli, if I read its purpose properly, is used to parse command line arguments.
<ldywicki>
anyhow, I see some strange output when I switch shell, maybe its a shell issue?
<ldywicki>
Looking at objdump I see RUNPATH, could it be related to it? It looks ok in dump: `RUNPATH $ORIGIN/../lib/jli:$ORIGIN/../lib`, but its definitely not considered when loading libjli (it is inside ../lib/jli))
florian has joined #yocto
<ldywicki>
sh-5.2# bash g ives me `bash: cannot set terminal process group (1): Inappropriate ioctl for device`, so its not only one place which is affected
<marex>
ldywicki: are you possibly running shell as init process , with some init=/bin/bash ?
<ldywicki>
could be, I can't see systemd being booted, I just went into it via runqemu slirp nographic serialstdio
<ldywicki>
(it is likely that I do something wrong, I am running qemu inside docker through kas-container)
<ldywicki>
thats tutorial which explained all the mystery of it
<ldywicki>
I do have machine set to qemuarm64, so I have qemuboot etc created, but indeed it somehow does not show a regular prompt I would expect. Will do clean build.
frosteyes has quit [Ping timeout: 268 seconds]
goliath has quit [Quit: SIGSEGV]
<ldywicki>
I've been messing with x86-64 and arm64, maybe it left some pollution in work, I don't know.
<marex>
well kas does scrub some of the environment, but that shouldn't propagate into qemu I think (maybe it does)
<ldywicki>
it might be due to qemu inside docker, yet I always had troubles calling (or actually configuring) bitbake on my host
florian has quit [Ping timeout: 256 seconds]
merit_ has joined #yocto
merit has quit [Remote host closed the connection]