ehussain has quit [Remote host closed the connection]
ehussain has joined #yocto
Bardon has joined #yocto
florian has quit [Ping timeout: 252 seconds]
rob_w has quit [Remote host closed the connection]
vthor has quit [Excess Flood]
vthor has joined #yocto
vthor has quit [Changing host]
vthor has joined #yocto
nayfe has joined #yocto
<nayfe>
Hello all, hope you're doing fine. In my product, I add a jar from external build and I'm wondering if it's possible to inject unpatched CVEs into corresponding Yocto recipe ? Maybe by creating dummy recipes for each products inside jar? but it'll be a lot
PhilD has joined #yocto
florian has joined #yocto
<PhilD>
Looks like cracklib renamed their master branch -> main, removing the master branch and breaking our yocto build (someone else has spotted this here: https://github.com/cracklib/cracklib/issues/109).
<PhilD>
Is there a better way of fixing this than creating a bbappend and tweaking the SRC_URI?
<mcfrisk>
PhilD: submit branch change fix to oe-core/poky master and stable/LTS branches
<landgraf>
PhilD: PREMIRROR ?
<landgraf>
or upstream fix
<PhilD>
OK Thanks, I'm stuck on outdated branches due to vendor tooling (Xilinx PetaLinux). I'll do the bbappend for now and have a look at PREMIRROR.
xmn has quit [Ping timeout: 248 seconds]
<Granjow>
qschulz: Remember the Marvell ethernet adapter for the Siemens BX-21A which I did not get running because I did not know which PHY to use? I now booted a live Ubuntu, which loaded the correct modules, so I could spy there, enable the adapter (CONFIG_STMMAC_ETH /_PCI, not sure which, I have both active), and it works :D
<qschulz>
Granjow: nice ~o~
xmn has joined #yocto
wooosaiiii has quit [Remote host closed the connection]
mbulut has joined #yocto
leon-anavi has joined #yocto
xmn has quit [Ping timeout: 260 seconds]
mjm has quit [Ping timeout: 252 seconds]
PhilD has quit [Quit: Client closed]
wooosaiiii has joined #yocto
wooosaiiii has quit [Remote host closed the connection]
olani has quit [Read error: Connection reset by peer]
olani has joined #yocto
albeu has quit [Changing host]
albeu has joined #yocto
<albeu>
Hi! Is it possible/supported to use bitbake 2.10 for scarthgap?
<rburton>
albeu: its not tested. why?
<rburton>
you could try it and see, but if it breaks you get to keep the pieces
<albeu>
Several bug fix have not been backported to 2.8
<rburton>
be the change you want in the world: backport the fixes and post the patches
<albeu>
For me the file-checksum hash issue is quiet relevant as I then have less than 50% sstate match with my build server
mjm has joined #yocto
<albeu>
I can do that but I'm still unclear what the polices are for backports.
<nayfe>
rburton would you have a hint for my problem please? no is a valid answer :D
Granjow has joined #yocto
Guest66 has joined #yocto
Guest66 has quit [Client Quit]
Kubu_work has quit [Quit: Leaving.]
Kubu_work has joined #yocto
DharmeshRobertBo has quit [Ping timeout: 256 seconds]
kanavin has quit [Remote host closed the connection]
mvlad has joined #yocto
<Granjow>
Where does the final kernel configuration go so I can check it? kernel-source/.kernel-meta/cfg/ in work-shared does not provide this information.
Daanct12 has quit [Quit: WeeChat 4.4.2]
<rm5248>
is there a way to list all -native packages? I think my problem with dnf is due to the SWIG interfaces being generated with an older version and I'm trying to make sure that they all get cleaned. oe-pkgdata-util doesn't seem to list -native packages
<mcfrisk>
Granjow: kernel-dev package, for example. or in the build directory after do_configure.
<Granjow>
mcfrisk: Which exactly would be the build directory? That sounds easier than swapping to kernel-dev.
sakoman has quit [Remote host closed the connection]
sakoman has joined #yocto
<mcfrisk>
Granjow: depends a lot on layers and kernel recipes. A lot of variables in the path too. For example on qemuarm64-secureboot meta-arm machine build with linux-yocto kernel it's build/tmp/work/qemuarm64_secureboot-poky-linux/linux-yocto/6.10.11+git/linux-qemuarm64_secureboot-standard-build/
<mcfrisk>
Granjow: I mean binary package kernel-dev, it is easy to extract from build/tmp/deploy/ipk/qemuarm64_secureboot/kernel-dev_6.10.11+git0+4bf82718cf_6c956b2ea6-r0_qemuarm64_secureboot.ipk for example
<mcfrisk>
if kernel build was taken from sstate, then work directory will not contain the .config but kernel-dev binary package will
<Granjow>
mcfrisk: I don't seem to have an ipk file anywhere, is that possible?
<Granjow>
Basically the question I'm trying to answer is if the watchdog is loaded correctly because I enabled it in the kernel configuration. There is no warning saying it was not activated, so I assume it is, and I have a /dev/watchdog and a /dev/watchdog0 (not sure why I have 2), but when I crash the system with a kernel panic, the watchdog does not
<Xogium>
Granjow: did you configure the watchdog in systemd ? If so, you should see something similar to this
<Xogium>
systemd[1]: Using hardware watchdog 'STM32 Independent Watchdog', version 0, device /dev/watchdog0
<Xogium>
systemd[1]: Watchdog running with a timeout of 30s.
<mcfrisk>
Granjow: answer depends on your layers, recipes, distro and machine features, preferred recipes and version. In general effective kernel config is available in kernel-dev binary package after build, and in kernel recipe build tree after do_configure
<Xogium>
as for why watchdog and watchdog0, watchdog is a symlink to watchdog0
Daanct12 has joined #yocto
<Granjow>
Xogium: I have the “using hardware watchdog” statement, but not the timeout. However the config file /etc/systemd/systemd.conf.d/watchdog.conf exists and contains the configuration [Manager] RuntimeWatchdogSec=32s.
Xagen has quit [Remote host closed the connection]
<Xogium>
huh. That is weird
Xagen has joined #yocto
Xagen has quit [Client Quit]
<Granjow>
mcfrisk: What approach can I take to find the path for my layers/recipes/etc.? I really have no clue where to start with.
Daanct12 has quit [Quit: WeeChat 4.4.2]
<Granjow>
Xogium: Ok, I searched for lowercase watchdog and did not see that one line below it says that it configured the watchdog to 32 s. I removed the unit because s is not documented, only ms/min/h/d/w, but it makes no difference.
paulg has joined #yocto
<Xogium>
right so it should definitely be taken into account
<Xogium>
in other words causing a panic should reset your hardware
bhstalel has joined #yocto
mbulut has quit [Ping timeout: 252 seconds]
<mcfrisk>
Granjow: bitbake -e $YOUR_IMAGE, then check what is the selected kernel recipe from PREFERRED_PROVIDER_virtual/kernel variable. For plain poky it's linux-yocto. Then "bitbake -c configure linux-yocto" will run the config step and recipe work directory will have the effective .config file. Path depends on host, distro, architecture etc.
DvorkinDmitry has joined #yocto
Xagen has joined #yocto
<DvorkinDmitry>
is it possible to generate package-lock.json for NPM package at the runtime?
<Granjow>
mcfrisk: I'm feeling like a noob (I hardly use bitbake because of kas). When I run bitbake -e, I get so many lines that my bash history overflows. Where do I have to look at?
<mcfrisk>
Granjow: bitbake -e shows all bitbake environment variables and how they were formed by configs in layers, recipes etc. pipe to file or less and search for the variable in question.
<Granjow>
mcfrisk: Ah. I remember. I have used that once last year. Thanks. I've now configured linux-intel.
goliath has quit [Quit: SIGSEGV]
Saur_Home39 has quit [Quit: Client closed]
Saur_Home39 has joined #yocto
florian_kc has joined #yocto
<Granjow>
mcfrisk: So, now after running configure, what can I look for?
druppy has joined #yocto
druppy has quit [Client Quit]
sofsal has joined #yocto
druppy has joined #yocto
<rburton>
Granjow: bitbake-getvar also works better for a single variable. "bitbake-getvar PREFERRED_PROVIDER_virtual/kernel"
<rburton>
if you've a recent release, "bitbake virtual/kernel -c showconfig" will tell you where the config file is in the build tree
<rburton>
actually how does that help - as you say the wheel is intermediate
<yocton>
the RECORD file is still installed
CrazyGecko has joined #yocto
<rburton>
ah ok yeah
<yocton>
In fact, the RECORD file is recreated from scratch by python-installer instead of just taking the one in the wheel file
Saur_Home49 has quit [Ping timeout: 256 seconds]
<yocton>
... recreated from zipfile/whl order which is not stable when outputed by maturin :o)
<rburton>
its a workaround but its not a silly one :)
ederibaucourt has quit [Ping timeout: 272 seconds]
ederibaucourt has joined #yocto
Saur_Home7 has joined #yocto
aduskett has quit [Read error: Connection reset by peer]
aduskett has joined #yocto
aduskett has quit [Client Quit]
Saur_Home42 has quit [Ping timeout: 256 seconds]
xmn has joined #yocto
CrazyGecko has quit [Ping timeout: 272 seconds]
fabatera_ has joined #yocto
fabatera has quit [Quit: Client closed]
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #yocto
PhoenixMage has quit [Ping timeout: 265 seconds]
sofsal has quit [Ping timeout: 256 seconds]
PhoenixMage has joined #yocto
kanavin has joined #yocto
PhoenixMage has quit [Ping timeout: 252 seconds]
albeu has quit [Quit: albeu]
PhoenixMage has joined #yocto
Saur_Home95 has joined #yocto
Saur_Home7 has quit [Ping timeout: 256 seconds]
jmd has joined #yocto
PhoenixMage has quit [Ping timeout: 246 seconds]
PhoenixMage has joined #yocto
fabatera_ has quit [Ping timeout: 260 seconds]
Saur_Home95 has quit [Quit: Client closed]
Saur_Home95 has joined #yocto
florian has quit [Ping timeout: 252 seconds]
florian has joined #yocto
Tyaku has joined #yocto
Saur_Home73 has joined #yocto
<Tyaku>
Hello, I have an interrupt issue on my system: When I echo fastly to "/dev/ttySC1" I get a message like a kernel panic with 'Unbalanced enable for IRQ 69' But all my problem is to know where 69 comes from. If I do a "cat /proc/interrupts", 69 does not appear in the list
<Tyaku>
Did someone know where to search ? Is this number related to "Interrupt ID" from the chip being used ?
<Tyaku>
(maybe not because the numbers in /proc/interrupts does not correspond to the sames interrupt.
Saur_Home95 has quit [Ping timeout: 256 seconds]
<Tyaku>
I try to check in the DTS (r9a07g043.dtsi) but I don't see the relation with the "interrupt id" from /proc/interrupts (or from my panic)
leon-anavi has quit [Quit: Leaving]
PhoenixMage has quit [Ping timeout: 246 seconds]
nayfe has quit [Quit: Client closed]
PhoenixMage has joined #yocto
<khem>
Tyaku:something to do with Interrupt controller on Renesas SOCs