<KanjiMonster>
rmilecki: interesting, streaming over wifi stalled after a few seconds on a gl-mt300n v2 (mt7628an), while wired was fine (using a chromecast)
<rmilecki>
KanjiMonster: can you give it a try? that would be very helpful
<KanjiMonster>
rmilecki: just came back (yesterday) from a vacation with a cold, so maybe in a few days
<rmilecki>
KanjiMonster: take your time!
<ILEoo>
hi all, what is the usuall pace for openwrt-packages PR reviews? And should I poke someone specific for python-related packages?
robimarko has joined #openwrt-devel
<\x>
slh: got it to work seems theres a macro change
<f00b4r0>
i'd argue the same should be done for packaging IB/SDK etc
<robimarko>
Agreed, i think they are similar PR-s for that as well
SlimeyX has quit [Ping timeout: 480 seconds]
<aparcar>
robimarko: Don't we need xz anyway for device compression?
<robimarko>
aparcar: Yes, for squashfs and kernel uses it as well for ARM and some other archs
<robimarko>
But we could still work on moving away from it
<robimarko>
Especially on stuff fully under OpenWrt control
<aparcar>
isn't xz still the best compression algo?
<robimarko>
Size wise yes as far as I know
<robimarko>
But its also one of the slowest for compression/decompression time
<f00b4r0>
it's marginally better and not in all cases
<f00b4r0>
and that's a poor technical argument in the face of what happened
<aparcar>
I guess we should do ib/sdk/dl switch to zst anyway
<f00b4r0>
it's also the worst in terms of resilience, a single bitflip can make an xz archive irrecoverable
<aparcar>
resilience isn't really my focus here
<f00b4r0>
for source archival it should certainly be
<f00b4r0>
otherwise what's the point.
<aparcar>
using checksums
<f00b4r0>
if you can't validate checksum because the comparison is corrupt *and* you can't recover the comparison source, what did you achieve?
<f00b4r0>
anyway, in most cases we're probably looking at half a % of size difference, if that's the only argument for keeping xz around, then I just give up ;P
<robimarko>
For build machines that doesnt matter at all
<aparcar>
historically we try to keep images as small as possible to run on embedded stuff
<robimarko>
Yes, but this doesnt change that at all
<f00b4r0>
yes, changing how we package our source and IB/SDK has no bearing on what compression is used for images. I understand the point for images, but note that they aren't using 'xz' either, they're using LZMA, on which xz is based.
<f00b4r0>
(and has become the de-facto utility to de/compress LZMA)
<\x>
rmilecki: yeah man, having HT40+/- like control on newer standards be nice
<robimarko>
f00b4r0: I think that kernel does use XZ directly for piggy-data, etc
<robimarko>
But yeah, rest is using LZMA
<aparcar>
well let's hope LZMA is fine then
<f00b4r0>
it has its own problems, but nothing nearly as bad as xz
<f00b4r0>
;)
<f00b4r0>
also on the plus side, because zstd is massively faster to de/compress, this will lower out build times. That alone is a win.
<aparcar>
robimarko: do you want to continue the work? I think just s/zstd/zst/ and a build-prereq zstd is missing
<f00b4r0>
robimarko: didn't know that. I hope they reconsider soon ;P
<robimarko>
aparcar: we already ship zstd as part of tools build
<KanjiMonster>
I think the identical single- vs multithreaded results compared to xz is a good argument for zstd, and the PR could use some numbers showing that the size difference is minimal (and maybe also time to (de-)compress)
<robimarko>
f00b4r0: Well, it seems that kernel offers multiple options for compressed boot data
<robimarko>
Including LZMA
<f00b4r0>
KanjiMonster: see archlinux ml link above :)
<robimarko>
We are the ones selecting XZ now via CONFIG_KERNEL_XZ=y
<f00b4r0>
*sigh*
<f00b4r0>
we really shouldn't be doing that.
<KanjiMonster>
f00b4r0: "the PR could use" - it's nowhere written in the PR, where the information needs to be
<f00b4r0>
if only because bitflip on flash storage *can* happen.
<f00b4r0>
KanjiMonster: yes, I was hinting at such a source of numbers, in case it was missed
<f00b4r0>
anyhow, lunch time, bbl
Daanct12 has joined #openwrt-devel
fda has joined #openwrt-devel
shibboleth has quit [Quit: shibboleth]
<ynezz>
robimarko: hi, BTW what do you use as your build host?
<aparcar>
I'll catch up on this conversation in a bit got a meeting now
<ynezz>
BND meeting? :P
<aparcar>
ynezz: yea time to infiltrate zstd
<ynezz>
yeah, I asked Chat GPT exactly for that: give me a three letter german agency which might be interested in backdooring openwrt: The German agency that might have an interest in the security aspects of technologies like OpenWrt, which includes considerations around backdoors for surveillance or security purposes, is the BND, Bundesnachrichtendienst (Federal Intelligence Service).
<ynezz>
keeping jokes aside, I'm wondering how to improve that situation about the source code package integrity checks
<aparcar>
do you want to stop building packages if the integrity check fails?
<KanjiMonster>
using git would severily increase download times and space usage (e.g. downloading the kernel would be a ~5 GiB checkout vs a ~130 MiB tarball), and we would need to come up with a way of caching/storing git trees to avoid recloning on every rebuild/clean etc
<aparcar>
you can do a shallow clone afaik
<aparcar>
also it would end up on sources.openwrt.org
<ynezz>
particularly in this mdio-netlink case the Git is going to clone using Git tag reference of PKG_SOURCE_VERSION:=1.3.1
<ynezz>
and having malicious upstream anyone can move that Git tag 1.3.1 to whatever else
<KanjiMonster>
also we should avoid referencing tags, as tags can be retargeted
<ynezz>
yep, indeed
<ynezz>
so adversary can change it even on the fly, targeting just some builds
<ynezz>
nightmare
<KanjiMonster>
using a non-shallow persistent clone means that on updates you only need to do a git fetch on the persistent tree copy, and don't need a full clone; this is how yocto operates
<aparcar>
tags + pkg_hash are good enough, not?
<ynezz>
try it
<aparcar>
I mean we usually use that already, don't we?
<ynezz>
does it look to you, that we do that already?
<ynezz>
that source package integrity changed after those apk changes, yet we still happily provide mdio-tools ipk
<aparcar>
so that's a deeper issue in the build system
<robimarko>
Because this effectively made all of these valid versions invalid over night
<ynezz>
aparcar: but it should insist on the PKG_HASH even after the checkout
<aparcar>
ynezz: can you open an issue an assign me?
Daanct12 has quit [Quit: WeeChat 4.2.1]
<ynezz>
aparcar: in this case of PKG_SOURCE_VERSION:=1.3.1 this is going to end up as a Git references, which is very weak
<aparcar>
robimarko: well agree it's a bummer, but then again I see no other way if we want to collaborate with upstream APK
<robimarko>
ynezz: I see your point, tags can be "edited"
<aparcar>
ynezz: yea I get the point. So we should always require a PKG_HASH and fail if it doesn't check out
<Znevna>
openwrt devel sounds fun post-xz
<robimarko>
I wish injecting malware was fun
<KanjiMonster>
aparcar: from the naughty list "libopenssl-afalg_sync 1.2.0-beta.1-r5" - I see an example following this versioning in https://semver.org/ in the example at 11.4 ("1.0.0-beta.2"), or do I miss something?
<aparcar>
KanjiMonster: right now APK expects `1.2.0_beta1-r5`
<aparcar>
so apk doesn't cover the full semver spectrum
<KanjiMonster>
_ isn't a valid character for semver, so it feels misleading to point to semver.org in this case, especially if this difference isn't mention anywhere in the PR
<aparcar>
yea agree, I didn't check that semver includes all those corner cases
<aparcar>
thanks for pointing that out
<KanjiMonster>
is there a document describing how apk handles versions? especially ordering?
<rmilecki>
seems to report mt7603 watchdog regression
<robimarko>
mrnuke: I will look at those
<mrkiko>
ynezz: do you already know the SoC on which it's based?
minimal has joined #openwrt-devel
shibboleth has joined #openwrt-devel
<robimarko>
mrkiko: Since mrnuke has it my guess is IPQ9574
<robimarko>
If it only wasnt 400+ EUR
<mrkiko>
robimarko: oh, didn't notice it was the same model. Thanks
<mrkiko>
but I am probably not up-to-date- on what ipq95xx parts are upstreamed / "usable" and what are not. I remember the tharget was submitted but it was uart-only at that moment
<mrnuke>
I think its IPQ9554 (according to SoC ID)
<robimarko>
Close enough
<mrnuke>
mrkiko: I got ethernet working with some help from qca-ssdk. Also got ath12k loading, but failing after firmware upload
<mrnuke>
mrkiko: the patches I linked earlier are to enable PCIe link to the ath12k device
<robimarko>
mrnuke: Did QCA upstream the remoteproc driver that is just an SCM interface?
<mrnuke>
robimarko: I'm not sure. ath12k tries to use something called "mhi"
<robimarko>
Oh, so its just external card then
<mrkiko>
mhi = 5G modems
<robimarko>
Not just modems
<robimarko>
All QCA modern WLAN cards use MHI as well
<robimarko>
Anything can implement it
<jakllsch>
so, sort of like TI VLYNQ?
<mrkiko>
robimarko: oh, so my nbd7815 is already old :D :D
<robimarko>
mrkiko: Well, if 802.11be is a thing you need
<mrkiko>
:D
<robimarko>
I am holding off until they are affordable, cause 400+ EUR aint cheap for HW to play with
<mrnuke>
I got mine for $250. Must have been an amazon sale
<robimarko>
mrnuke: Only 163,55 USD more for shipping and VAT to Croatia
<robimarko>
CI is just so painfully slow
<mrnuke>
"Only"...
<f00b4r0>
bit late to the party sorry
<f00b4r0>
ynezz: if upstream is malicious we're fucked anyway, which is a strong argument for relying on bits that have a *lot* of eyes looking (i.e. zstd vs xz being a prime example)
<f00b4r0>
we need to build on "the shoulders of giants", not on those of "that random person in Nebraska", imho
<jakllsch>
eh
<jakllsch>
does zstd have eyes on it outside Meta?
<f00b4r0>
it already has more eyes inside Meta than xz had at all
<robimarko>
ZSTD is quite popular
<f00b4r0>
and it has a proper documented design
<f00b4r0>
and none of its nightmarish flaws
<jakllsch>
true
<jakllsch>
i've seen the scathing review from the lzip people
<f00b4r0>
then you know what I'm talking about :)
<mrkiko>
jakllsch: yeah, I was also impressed by that review until I discovered there is apparently no public repo for lzip, happy to be proved wrong here
<mrkiko>
jakllsch: btw (to be sure we're on the same page) - I am talking on the document where they criticize xz for it's complexity, algorithms extensibility and so on, the one where they say it was designed to accomodate for algorithms like algorhtms where cars on a factory
<f00b4r0>
nbd: purely FYI the mt7915 thing seems to correlate with number of ap/radio. It *seems* to be harder to reproduce with fewer aps, although it's from very limited testing so far
goliath has quit [Quit: SIGSEGV]
<nbd>
rmilecki: sorry, patch was buggy, will have a new one soon
mattsm has quit [Ping timeout: 480 seconds]
fakuivan has quit [Remote host closed the connection]
fakuivan has joined #openwrt-devel
fakuivan has quit [Remote host closed the connection]
fakuivan has joined #openwrt-devel
fda has joined #openwrt-devel
<mrnuke>
robimarko: `make dt_binding_check -j 12 DT_SCHEMA_FILES=qcom,pcie` gives me a couple of warning for qcom,pcie.yaml. Same warnings if I don't apply my changes. Should I worry about that?
<robimarko>
mrnuke: Most likely you should fix those first
<rmilecki>
mrnuke: one minor mistake, otherwise looks good
<mrnuke>
I'll take "one minor mistake" given I don't understand how dt-schema works :)
<mrnuke>
rmilecki: when are minItems and maxItems required?
<rmilecki>
mrnuke: for properties with not hardcoded values I'd say
<rmilecki>
mrnuke: for properties like "reg-names", "clock-names", "reset-names", etc. you have a static list of values
<rmilecki>
(exception: values differ depending on chipset)
<rmilecki>
mrnuke: so minItems & maxItems you use for lists: reg, clocks, resets, etc.
<mrnuke>
before I touched "qcom,ipq8074-qmp-pcie-phy.yaml", it only had "maxItems:" As soon as I split it up depending on "compatible", "make dt_binding_check" started complaining.
<mrnuke>
Did I handle things correctly by adding a "minItems"?
c512l has joined #openwrt-devel
kirdesde has quit [Ping timeout: 480 seconds]
<rmilecki>
mrnuke: i believe you did it correctly
c512l has quit [Read error: Connection reset by peer]