00:17 <owrt-images-builds> Build [#100](https://buildbot.openwrt.org/images/#/builders/220/builds/100) of `master_mpc85xx/p2020` failed.

02:01 <Namidairo> 7915 seems more or less fine for me, I just didn't look in on the device I had it in and came back to a big conga line of "uh-oh the stock layout limits kernel to 4M and now it don't build" and two different PR's about it

09:39 <jow> anyone using Safari on Mac here?

09:41 <jow> we got a report that it automatically decompresses .gz firmware image downloads which leads to confusion since the resulting checksums will obviously not match the ones reported omn the dwonload page

09:41 <jow> at first I thought this can be prevented by delivering image downloads with an applications/octet-stream mime type instead of a gzip one but this already is the case

09:41 <f00b4r0> that's correct

09:41 <f00b4r0> depends on settings

09:42 <jow> and now I wonder if this heuristic is based on file extension or content sniffing

09:42 <jow> in the former case I'd lobby for renaming our various .img.gz images to just .img or .bin, something I bring up from time to time again

09:42 <f00b4r0> there's a setting in "General" that says it will automatically open "trusted" files

09:42 <f00b4r0> I have it unchecked for that very reason

09:42 <jow> since the gzip compression is an implementation detail, users are not meant to decompress or interprete such images

09:44 <jow> we also get infrequent report about "broken" images because gzip (or various gui archivers) report decompression errors (trailing garbage) due to the image metadata appended to .img.gz images

09:44 <f00b4r0> yep i've seen that too :)

09:46 <f00b4r0> seems to be extension-based: https://www.blackmanticore.com/1c569206754935dacb0dc6b89ca818b8

09:46 <jow> so technically these are not "gzip files" but proprietary binary files that happen to compress (parts of) their content with gzip

09:47 <jow> on top of renaming them I'd even go as far as masking the gzip header

09:48 <jow> and unamsking it in sysugprade

09:48 <f00b4r0> makes sense

09:48 <Habbie> XOR it with 'sysupgrade'

09:49 <jow> yeah, something like that

09:49 <f00b4r0> note this also affects backups

09:49 <f00b4r0> (though it's pretty harmless there)

09:50 <jow> Habbie: oh, "sysupgrade" happens to be 10 bytes, so it neatly covers the 10 byte gzip header even :)

09:50 <Habbie> hah

09:50 <Habbie> i did not know that

09:53 <f00b4r0> jow: btw, dunno if you saw my pm? :)

10:38 <PaulFertser> Masking the gzip header is too nasty. While reasoning about not naming them .gz is solid mangling the contents to fool some broken software will also fool some users who know what they're doing and just want to unpack manually for whatever reason they might need it for.

10:42 <dwfreed> a user that knows what they're doing can spend 5 seconds to read the sysupgrade source and see that it hides the gzip header

10:43 <dwfreed> but also one could just put some text before the gzip header, should be sufficient

10:45 <jow> true, probably better even since it can be simply skipped/seeked

10:47 <PaulFertser> Please do not break just regular binwalk invocation :/

10:48 <dwfreed> I mean, binwalk would probably quickly learn to identify sysupgrade images with mangled gzip header

10:49 <f00b4r0> if the file isn't valid gzip it probably shouldn't claim to be anyway

10:49 <dwfreed> but a header before the gzip header shouldn't fool binwalk at all

10:49 <dwfreed> f00b4r0: I mean, "valid" here is relative

10:50 <f00b4r0> well no. Either it conforms or it doesn't :)

10:50 <PaulFertser> OpenWrt is already special /enough/. Violating principle of least astonishment just to make users of some marginal broken software happy sounds like a bad idea.

10:50 <Habbie> agreed, text makes more sense than xor

10:50 <f00b4r0> *nod*

10:50 <dwfreed> f00b4r0: then technically it *does* conform to gzip standard

10:51 <f00b4r0> dwfreed: with trailing garbage though :)

10:51 <dwfreed> that is allowed

10:51 <PaulFertser> Is renaming not enough anyway?

10:51 <f00b4r0> indeed

10:51 <PaulFertser> I mean nobody claims it's a gzip file if it's not named as such.

10:52 <f00b4r0> from the pov of safari i'm pretty sure renaming is enough. After all it doesn't try to unpack ipks

10:55 <dwfreed> other things might do content sniffing, though

11:48 <rmilecki> it seems it's time for me to give up on mt7621 / mt7628 devices I have

11:48 <rmilecki> I'm somehow disappointed with mt76, I hoped for it to be really problem free

11:50 <rmilecki> so I started looking what may be another CHEAP MediaTek SoC and I found mt7622 (ARM so maybe even faster)

11:50 <rmilecki> next thinkg I found out however is that mt7622 often comes with mt7915 (Linksys E8450, Netgear WAX206)

11:50 <rmilecki> and f00b4r0 let me know yesterday that mt7915 isn't stable with mt76 neither?!

11:50 <rmilecki> so is there a good MediaTek option at all?

11:51 <robimarko> MT7981 maybe?

11:51 <robimarko> Its definitively cheap and much more modern than MT7622

11:52 <rmilecki> what chance is that this one will be stable? :/

11:52 <robimarko> I guess that depends on your definition of stable

11:53 <rmilecki> capable of carrying wireless traffic without stops like [ 3] 50.0-51.0 sec 0.00 Bytes 0.00 bits/sec

11:54 <robimarko> Not much you can do other than try it out

12:35 <castiel652> rmilecki from my experience mt7915 is quite stable. I put one as AP at my parents house and never got any complaints :D

13:11 <stintel> robimarko: I have that locally for a couple of months, but since there was open discussion about kernel bumps ...

13:11 <robimarko> stintel: qoriq 6.1?

13:12 <stintel> ack

13:12 <robimarko> Even if we move to 6.6 (I hope so) having 6.1 already there aint going to hurt

13:14 <mrkiko> robimarko: out of curiosity - what is happening with the ath11k firmware? I mean, apart from repository move, will the firmware be further developed / updated / maintained or not?

13:15 <robimarko> mrkiko: They are just standardising the place for the official FW

13:15 <robimarko> ath11k wont be developed as far as any features are concerned

13:15 <robimarko> But there are way newer versions in QSDK that we have asked QCA to publish

13:16 <mrkiko> robimarko: got it... was interested to know about bugfixes in general

13:16 <rmilecki> robimarko: any response from QCA?

13:16 <robimarko> Just the usual, we are in contact internally

13:16 <robimarko> But they usually eventually do push them public

13:17 <robimarko> As there is no reason not to, ipq60xx for example completely lacks 2.9.0.1 FW in public but in QSDK ipq8074/6018/9074 use the same FW versions

13:18 <mrkiko> jow: in the case of gl-b2200 installation, the user is expected to decompress the image at the moment

13:22 <stintel> so what's the decision for doing kernel bumps as of now to better maintain history

13:23 <robimarko> Script from oliv3r seems to work fine

13:23 <stintel> ok, I'll try to do it one of these days

13:24 <stintel> right now it's not the time, in the middle of a real estate deal and that is proving stressful and time consuming

13:30 <mrkiko> I completely disagree or renaming .gz files or altering them at all; also due to the reason I pointed out (e.g.: in some commits, at least the one for the b2200, instructions say so). Furthermore, I don't think I would arrive in 5 seconds at the conclusion I should look at sysupgrade. I don't think I'm the only one. :)

14:22 <jow> mrkiko: well the idea is to rename .gz images that are *not* meant to be unpacked

14:45 <mrkiko> jow: fine then...

16:39 <oliv3r> o/