<expert[m]>
<LetoThe2nd> "expert: then my suggestion would..." <- I learned it from watching you! 😫
<expert[m]>
I started from poky minimal, which is why I'm so surprised graphics gets pulled in. I'm only doing the BSP right now, but maybe it's the meta-rockchip layer I'm using?
<expert[m]>
LetoThe2nd: In all seriousness though, thank you so much for the live coding videos, quite a bit of the time, you are drinking beer on my second monitor (which also doesn't help with looking like I'm hard at work 😃).
JaMa has quit [Ping timeout: 264 seconds]
vladest has joined #yocto
mckoan_ is now known as mckoan
<mckoan>
good morning
<Guest40>
morning
rfuentess has joined #yocto
goliath has joined #yocto
zpfvo has joined #yocto
shoragan_ has joined #yocto
jonesv has quit [Ping timeout: 260 seconds]
tleb has quit [Ping timeout: 260 seconds]
Guest8948 has quit [Ping timeout: 260 seconds]
hays has quit [Ping timeout: 260 seconds]
bryanb has quit [Ping timeout: 260 seconds]
shoragan has quit [Ping timeout: 260 seconds]
jonesv has joined #yocto
tleb has joined #yocto
bryanb has joined #yocto
raghavgururajan has joined #yocto
beneth has quit [Read error: Connection reset by peer]
zpfvo has quit [Ping timeout: 250 seconds]
Vonter has quit [Ping timeout: 246 seconds]
frieder has joined #yocto
<expert[m]>
<rburton> "expert: remove x11 and wayland..." <- And others will be able to put one back in later right?
<expert[m]>
Thanks This is what I already did, was just wondering if it was the correct way to do it
<rburton>
expert[m]: the correct way is you define your own distro which has the features you want
zpfvo has joined #yocto
Guest40 has quit [Ping timeout: 246 seconds]
mvlad has joined #yocto
<RP>
khem: I've not ridden scarth gap but it is on my list!
vladest has quit [Ping timeout: 260 seconds]
JaMa has joined #yocto
<LetoThe2nd>
expert[m]: hehe thanks, glad if people find my stuff helpful
zpfvo has quit [Ping timeout: 244 seconds]
zpfvo has joined #yocto
Guest48 has joined #yocto
vladest has joined #yocto
Kubu_work has joined #yocto
randomgeek has quit [Ping timeout: 245 seconds]
grma has joined #yocto
leon-anavi has joined #yocto
amitk has quit [Ping timeout: 252 seconds]
mrnuke has quit [Ping timeout: 252 seconds]
mrnuke has joined #yocto
Guest48 has quit [Quit: Client closed]
amitk has joined #yocto
frieder has quit [Ping timeout: 252 seconds]
<dacav>
Hello. While trying to use `devtool modify`, I often get this kind of errors:
<dacav>
> Exception: bb.fetch2.FetchError: Fetcher failure: Recipe uses a floating tag/branch '...' for repo '...' without a fixed SRCREV yet doesn't call bb.fetch2.get_srcrev() (use SRCPV in PV for OE).
<dacav>
I've got a situation which is similar to https://lists.yoctoproject.org/g/yocto/topic/61267838. The suggested solution is to replace SRCREV with a hash. This is effective, but a little annoying, since all I need is to modify the source code, and the revision would be somewhat dynamic anyway. How to I use "use SRCPV in PV for OE"?
<Guest62>
question: does anyone know which recipe if any is responsible for /proc/sys/kernel/osrelease file?
<landgraf1>
Guest62: /proc is virtual kernel filesystem
<Guest62>
indeed but this file has a string in it which is different from /lib/modules/<kernel version> hence my problem
<Guest62>
need to locate where my predecessor on the project went wrong
<Guest62>
modules compile with the correct string in it but will nnot load as the kernel carries something completely different as os-release string
<landgraf1>
Guest62: CONFIG_LOCALVERSION ?
<sudip>
Guest62: you need to have CONFIG_PROC_SYSCTL in the kernel
<Guest62>
thank you will check that
<Guest62>
PROC_SYSCTL is set at y
<sudip>
sorry, I have not read your full message. PROC_SYSCTL is to enable /proc/sys/kernel/osrelease
<Guest62>
CONFIG_LOCALVERSION is to add to the version string and is set but does not contain the string am after
jmk1 has quit [Ping timeout: 245 seconds]
jmk1 has joined #yocto
ray-san2 has joined #yocto
ray-san has quit [Ping timeout: 260 seconds]
Guest11 has joined #yocto
Guest11 has quit [Client Quit]
<KanjiMonster>
Guest62: have you checked /proc/config.gz for the value in your running kernel?
zpfvo has quit [Ping timeout: 244 seconds]
<mckoan>
Guest62: you can't mix modules and kernel versions
zpfvo has joined #yocto
<Guest62>
sudip: maybe I should ask the question differently: what would you chnage if you had to alter the content of /proc/sys/kerfnel/osrelease? and henceforth the response to uname -r
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
frieder has quit [Ping timeout: 246 seconds]
davidinux has quit [Ping timeout: 244 seconds]
davidinux has joined #yocto
<sudip>
Guest62: CONFIG_LOCALVERSION
<Guest62>
CONFIG_LOCALVERSION is set to "-l4t-32.6" which works fine as the name of /lib/modules/<kernel version> contains that
<Guest62>
however the /proc/sys/kernel/osrelease contains something completely different
<KanjiMonster>
Guest62: set where?
<Guest62>
well that is the $1,000,000 querstion
<KanjiMonster>
I mean where did take the value from
<Guest62>
KanjiMonster that is the point
<Guest62>
I have no idea as i inherited the project from a guy who left
<KanjiMonster>
how do you know that CONFIG_LOCALVERSION is set to "-l4t-32.6"? On which basis did you determine that?
<Guest62>
bitbake -c menuconfig virtual/kernel
<sudip>
Guest62: the string in osrelease is set in "init/version.c" file, and whatever value is in UTS_RELEASE
frieder has joined #yocto
<KanjiMonster>
Guest62: can you check /proc/config.gz on the device itself? (assuming you have this enabled)
<Guest62>
from decompressed config.gz on target
<Guest62>
cat config | grep LOCALVERSION
<Guest62>
CONFIG_LOCALVERSION=""
<Guest62>
# CONFIG_LOCALVERSION_AUTO is not set
Net147 has quit [Quit: Quit]
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
lamm has quit [Ping timeout: 260 seconds]
<KanjiMonster>
Guest62: so the booted kernel does not have LOCALVERSION set (set to an empty string)
<Guest62>
exatcly
<Guest62>
exactly
<Guest62>
root@guidance-jetson-xavier-nx-specs:/lib/modules# ls
<KanjiMonster>
so my guess now is that you aren't booting the kernel that you built
<Guest62>
in generated/utsrelease.h
<KanjiMonster>
which is why your uname -r says something unexpected
<Guest62>
so the problem would be in u-boot? in the kernel selection?
<Guest62>
not something I am famililar with
<KanjiMonster>
for example, that it loads the wrong kernel image. So you need to put the kernel where U-Boot expects it/loads it from, or alternative change the bootcmd to boot the right kernel
<manuel1985>
Can someone point me towards a testing framework to hardware-in-the-loop test an embedded system?
sakoman has joined #yocto
u4ia has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
xmn has quit [Ping timeout: 260 seconds]
kanavin has joined #yocto
zpfvo has quit [Ping timeout: 245 seconds]
<LetoThe2nd>
manuel1985: labgrid to some extent, fuego, lava...
zpfvo has joined #yocto
tepperson has joined #yocto
tepperson has quit [Client Quit]
tepperson has joined #yocto
<tepperson>
is there anything that would cause the root password over ssh to be different than the root password over console?
goliath has quit [Quit: SIGSEGV]
<manuel1985>
tepperson, is PAM enabled in your sshd config?
<manuel1985>
LetoThe2nd, thanks!
<tepperson>
manuel1985: i am using dropbear for sshd
<manuel1985>
tepperson, ok, then I've got no idea, sry
mason has left #yocto [#yocto]
<smooge>
with normal sshd there should not be a different password. however on EL8/9 it may be turned off to not allow logins via sshd. dropbear may be using the same rules and not allowing logins
frieder has quit [Remote host closed the connection]
mckoan is now known as mckoan|away
paulg has joined #yocto
jkridner has joined #yocto
<jkridner>
Who is best for me to start a discussion on getting BeagleV-Ahead into Yocto reference platform for RISC-V? I think it might require Beagle or T-Head to be Platinum sponsors…. Maybe I can get some help proposing that to Beagle/T-Head?
grma has quit []
<sakoman>
khem: RP: It looks like the commit which uncommented setting S and B in gcc-xx.x.inc is the upgrade from 11.3 to 12.1:
<sakoman>
Sadly no comment as to why this was done
<sakoman>
So this means kirkstone most likely has exactly the same issue
<sakoman>
I'm doing a dunfell test now which uncomments setting B (as khem suggested), but I wonder if S should also be uncommented??
Bardon_ has quit [Ping timeout: 260 seconds]
<kanavin>
jkridner, yes, the silicon vendor needs to be a project member pretty much, and allocate resources towards adding risc-v as a first class citizen architecture
<kanavin>
resources as in both humans doing the work and computers in the test cluster running the build
<kanavin>
before actual hardware becomes a reference, qemu emulation for it (qemurisc32/64) needs to be added and brought to same level of quality as the four primary architectures
Bardon has joined #yocto
tepperson has quit [Quit: Client closed]
<RP>
sakoman: it looks like the code is there to allow things like gcc from git to work so to work with different layouts. I suspect fixing B for dunfell/kirkstone should be fine
<RP>
jkridner: can you drop me an email about that. I have someone I can connect you to working in this area
<RP>
jkridner: I literally just got off a call talking to someone about the general riscv/YP challenge
zpfvo has quit [Remote host closed the connection]
<RP>
jkridner: I've sent mail
florian has quit [Quit: Ex-Chat]
grma has joined #yocto
rfuentess has quit [Remote host closed the connection]
<kergoth_>
RP: am I missing something, or can the parse cache dir grow unbounded, given it suffixes with data hash and symlinks to it, but there seems to be no cleanup of old files? We had a jenkins job run 1,000 bitbake commands in a debugging function (yes, I know, yikes :) and it grew to 250GB.