**** BEGIN LOGGING AT Sun Nov 22 02:59:57 2020
Nov 22 03:04:52 <aparcar[m]> Isn't mvebu on 5.4?
Nov 22 03:39:18 <Namidairo> i thought 4.19 was removed from master
Nov 22 10:08:49 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_kirkwood.html has been updated. (100.0% images and 98.5% packages reproducible in our current test framework.)
Nov 22 10:41:03 <mrkiko> ARE USB controllers in router sensible to frequent powerdown / powerups of any sort? Yeah, bizzare quesiton but wanted to know for planning e.g.: industrial uses ...
Nov 22 10:41:59 <mrkiko> Yeah, I know I'll have to avoid NAND, but I am focusing on USB controllers and ipq806x
Nov 22 10:52:28 * enyc meows
Nov 22 11:41:31 <mrkiko> meows ??
Nov 22 14:41:07 <damex> we have here edgerouter 12 with qca8511.  official firmware use some voodoo around binary packages without sources to configure it (kernel have no dedicated support for it there). it seems like it might be compatible with qca8k (dsa).
Nov 22 14:41:24 <damex> any idea how to find an address on which switch is present?
Nov 22 14:44:04 <damex> we found out (with lemmi) that it is using port based vlan and enabling DSA/QCA8K actually trigger something so port based vlan works.  idea is to get 1-8 ports of the er12 working.
Nov 22 14:44:35 <damex> without dsa/qca8k - it seem to act as a dumb switch
Nov 22 14:45:18 <lemmi> the default mapping is rather weird. vid 4094 maps to port 0, 4, 5, 6 and 7. vid 1 maps to port 1, vid 2 to port 2, vid to port 3
Nov 22 16:42:30 <swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html
Nov 22 17:50:34 <rr123> make package/feeds/packages/sqlite3/compile worked well, but make package/feeds/packages/sqlite3/install gave me 'no rule to make target package/feeds/packages/sqlite3/install', I did notice after 'compile' sqlite3 is already installed to ipkg-* directories, but still, manual step to run 'install' should not fail correct?
Nov 22 18:59:39 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_x86.html has been updated. (100.0% images and 98.4% packages reproducible in our current test framework.)
Nov 22 19:41:49 <rsalvaterra> Is it guaranteed that targets which define NAND_SUPPORT have their overlay partitions on ubifs?
Nov 22 20:28:16 <dangole> rsalvaterra: no, eg. mt7621 got NAND_SUPPORT but many boards use SPI-NOR and hence JFFS2 for overlay
Nov 22 20:30:03 <dangole> rsalvaterra: same goes for lantiq/xrx200
Nov 22 21:08:49 <karlp> rr123:make package/sqlite3/{clean,compile} the extra paths sometimes does weird things...
Nov 22 21:17:03 <rsalvaterra> dangole: Thanks. Well, that means the whole overlay compression thing is a f***ing mess. :(
Nov 22 21:17:57 <rsalvaterra> This function right here: https://git.openwrt.org/?p=project/fstools.git;a=blob;f=libfstools/overlay.c;h=eadafcf4391f36658c26f94c5fec770aeb6c743a;hb=HEAD#l341
Nov 22 21:18:34 <dangole> rsalvaterra: it's just depending on the underlaying storage provider. and that can either be nor-flash (->jffs2), block (->f2fs,ext4) or nand-flash (->ubifs)
Nov 22 21:18:41 <rsalvaterra> We're treating all overlays the same way, being jffs2, ubifs, ext4 or f2fs.
Nov 22 21:19:21 <dangole> rsalvaterra: there is one exception here which is how we deal with the super long amount of time jffs2 take to initialize....
Nov 22 21:20:14 <rsalvaterra> dangole: To initialize? To mount, you mean?
Nov 22 21:20:56 <dangole> rsalvaterra: to initialize/format, which is what the kernel does when you first mount an empty/unformatted jffs2 volume
Nov 22 21:21:48 <rsalvaterra> Ah, yes. But jffs2 is special. We should only be using it on small flash partitions (128 MiB tops).
Nov 22 21:22:16 <rsalvaterra> The sweet spot should be around 8-16 MiB.
Nov 22 21:22:51 <rsalvaterra> Did you see that function?
Nov 22 21:24:07 <rsalvaterra> I'm pretty sure that if I select OVL_MOUNT_COMPRESS_ZLIB on my Omnia, for example (which is using ext4 overlay), it'll blow up on my face.
Nov 22 21:24:49 <rsalvaterra> Unless the mount function is ignoring unknown options ("sloppy mount")…
Nov 22 21:28:12 <aparcar[m]> ynezz: is the collect.py script running on the new server? or should I implement it via a CI?
Nov 22 21:29:16 <aparcar[m]> zorun: thanks for the opkg patch
Nov 22 22:07:53 <aparcar[m]> jow: is there an eta for ucode to arrive in openwrt.git?
Nov 23 00:17:32 <rsalvaterra> Oh, my…! How old is the "add lzma support to jffs2" monster patch…? :|
Nov 23 00:18:09 <rsalvaterra> I mean, it surely must predate native kernel xz support (which is basically lzma)…
Nov 23 00:51:30 <dangole> rsalvaterra: it is very old...
Nov 23 01:02:36 <rsalvaterra> dangole: We really should just implement xz support in jffs2, but then there's that pesky backwards compatibility thing…
Nov 23 01:03:32 <dangole> rsalvaterra: i don't think we need to bother with jffs2 filesystems created with anything else than the kernel we are running
Nov 23 01:03:52 <dangole> would be nice to have tooling on the buildhost, but binwalk does the trick i guess
Nov 23 01:06:16 <rsalvaterra> dangole: Hm… ok, that's a big plus.
Nov 23 01:12:43 <rsalvaterra> Adding support for an existing compressor to jffs2 shouldn't be too hard, from what I can tell: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/jffs2?id=c799aca31bfe61ba3a91133acf5a13a0773087d4
Nov 23 01:12:56 <rsalvaterra> Of course, it also depends on the codec itself.
Nov 23 01:14:39 <Namidairo> does anything use libzstd in packages yet
Nov 23 01:14:44 <rsalvaterra> I may take a stab at it, one of these days.
Nov 23 01:18:33 <rsalvaterra> Namidairo: I don't think so, but we'll probably need it if we move squashfs from xz to zstd.
Nov 23 01:30:14 <aparcar[m]> rsalvaterra: sorry could you please summarize your plan?
Nov 23 01:31:19 <rsalvaterra> aparcar[m]: do I look like a guy with a plan? XD
Nov 23 01:32:20 <rsalvaterra> In all seriousness, though… of all native kernel compressors, I believe zstd provides the best speed/ratio trade-off.
Nov 23 01:33:37 <rsalvaterra> I think we could implement zstd support for jffs2 (which ubifs already supports) and get rid of that crazy lzma jffs2 patch.
Nov 23 01:34:51 <rsalvaterra> If people *really* want lzma, implementing both xz and zstd support for jffs2 would still be a much smaller patch than the existing one.
Nov 23 01:34:56 <aparcar[m]> we could add it for squashfs first can't we?
Nov 23 01:35:23 <rsalvaterra> aparcar[m]: Sure, I know you're already on it.
Nov 23 01:35:33 <aparcar[m]> rsalvaterra: *I was
Nov 23 01:35:39 <rsalvaterra> Oh.
Nov 23 01:35:52 <aparcar[m]> I thought you're the better candidate
Nov 23 01:36:10 <rsalvaterra> Well, this is long-term stuff, of course.
Nov 23 01:36:49 <rsalvaterra> aparcar[m]: I don't know if I'm the better candidate, but I do have a personal interest in it, for sure. ;)
Nov 23 01:37:18 * rsalvaterra wants to zstd all the things
Nov 23 01:39:09 <goliath> If someone's interested, 2 weeks ago I did a SquashFS serial *decompression* benchmark on a Debian image: https://github.com/AgentD/squashfs-tools-ng/blob/master/doc/benchmark.txt#L197
Nov 23 01:39:21 <goliath> Shiny graphs with compression ratio for comparison: https://github.com/AgentD/squashfs-tools-ng/blob/master/doc/benchmark.ods
Nov 23 01:39:31 <rsalvaterra> If these numbers still hold… https://lore.kernel.org/patchwork/patch/802867/
Nov 23 01:39:50 <rsalvaterra> … zstd will do wonders for boot times.
Nov 23 01:46:49 <rsalvaterra> At what xz level are we currently compressing the squashfs images?
Nov 23 01:47:28 <rsalvaterra> Decompression memory requirements are higher at higher levels, that's why I'm asking.
Nov 23 01:48:02 <goliath> rsalvaterra, AFAIK the highest with some micro management extra settings: https://github.com/openwrt/openwrt/pull/2916
Nov 23 01:52:31 <rsalvaterra> Oh, but we're using small blocks, so memory shouldn't be an issue.
Nov 23 01:53:35 <rsalvaterra> Off to bed now, almost 2 AM here. Bye!
**** ENDING LOGGING AT Mon Nov 23 02:59:57 2020