Staz97646298265307 has quit [Ping timeout: 480 seconds]
lairnc_ has joined #openwrt-devel
<lairnc_>
as a total newbie myself, what suggestions do you have to start getting to know the project and eventually contribute code?
<Habbie>
in general, i find a great way to figure out how to help, is finding something that you think is missing, or wrong, or could be better
ScrewDriver1337 has quit [Ping timeout: 480 seconds]
<slh>
lairnc_: the answer is pretty much the same for any opensource project. find a change you want to make, take care of some formalities https://openwrt.org/submitting-patches (which also are pretty similar almost everywhere, the signing off is pretty much the most important aspect) and then file the PR. take it slow, there is no hurry - do the things you care about
<\x>
is apk getting in for 24.xx?
<slh>
'maybeÄ ;)
<\x>
seems 6.6 going well for everything huh
<slh>
it's wanted, but it's also getting pretty late (imho 2-3 months too late already) for such a change
<\x>
is this the first time that openwrt will have a single kernel version for errything
<slh>
realtek is the only remaining real problem for kernel 6.6 (which would mean realtek would have to go)
<damo22>
does anyone here know how tplink devices that have kernel+rootfs in the same mtd partition have the kernel locate the rootfs when it mounts root?
<damo22>
are you supposed to pad the kernel out to a known offset and then hardcode that into the dts?
<f00b4r0>
stintel: i think we should just update the xdp-tools build recipe to point at the openwrt-hosted tarballs. Upstream has been unreachable (and breaking builds) forever
<f00b4r0>
;P
<f00b4r0>
oh that's even not it i see (should have read your gist first). Anyway, I've made it my new routine to always disable xdp-tools from my builds, I thought it was a download failure. I don't know how buildbots build it then if it FTBFS
<stintel>
qosify requires libxdp from xdp-tools so disabling that is not an option for me
<stintel>
6.6.48 on my backup m300 and still no chacha or poly in /proc/crypto
<stintel>
meh
<f00b4r0>
stintel: if it makes you feel any better, it's exactly the same on my M300 (running 22.03.7)
<stintel>
# CONFIG_CRYPTO_CHACHA20POLY1305 is not set
<stintel>
in build_dir/target-powerpc64_e5500_musl/linux-qoriq_generic/linux-6.6.48/.config
<stintel>
looks like there's some missing dependencies
<f00b4r0>
i don't know if "module:" is supposed to name the actual loaded module when the crypto implementation isn't builtin, but afaict, all the cyphers listed have "module: kernel"
<f00b4r0>
so I'm inclined to believe the list does not reflect loaded modules