01:56 <KGB-0> https://tests.reproducible-builds.org/openwrt/openwrt_x86.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)

04:59 <djfe> I have a question on ramips mt76 wifi

04:59 <djfe> when is it kmod-mt7615-firmware and when is it kmod-mt7615e?

05:00 <djfe> Or should all entries be switched from "e" to "-firmware"

05:02 <djfe> or is it "mt7615e" when the target requires "kmod-mt7663-firmware-ap"?

07:40 <rsalvaterra> Mangix: My overclocked RM2100 died on sysupgrade, now I need to recover it. I guess overclocking is still a Bad Idea™. :P

08:18 <djfe> tmn505: wouldn't it make more sense to port lzmaloader to IPQ40xx so we can avoid a compat-increase? (this is about your patchseries on the mailing list and ipq40xx bootipq on nor-flash)

08:46 <djfe> actually I just got a helpful tip. I'm testing out switching the image type to Device/FitzImage (from Fitimage)

08:47 <djfe> compressing the kernel with xz instead of gzip should yield a big reduction in Kernel size, so we will be a safe for a while longer and have time to decide what to do next.

09:03 <djfe> FitImage : 4310288

09:03 <djfe> FitzImage: 3064600

09:05 <djfe> it's a self-decompressing kernel so it's going to be a bit larger than that: 3099356, but that's a huge improvement and should last us a couple of years :)

09:22 <rmilecki> RoganDawes: brcmfmac4334-sdio.bin is included in official firmware repo: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/brcm

09:22 <rmilecki> RoganDawes: you may just need to include or package it in OpenWrt

09:23 <rmilecki> RoganDawes: i just checked, you need to create a new "brcmfmac-firmware-4334-sdio" package for OpenWrt

09:23 <rmilecki> RoganDawes: i'll be really simply, copy & paste mostly, see package/firmware/linux-firmware/broadcom.mk

09:23 <rmilecki> RoganDawes: good luck!

09:26 <rmilecki> Mangix: i'm not sure how I can help about E7350 or EIF RNG thing, did I miss something? :)

09:47 <rsalvaterra> I found an interesting corner case in our system. include/target.mk enables specific features depending on a (sub)target's kconfig (e.g. FEATURES += rtc if CONFIG_RTC_CLASS=y), right?

09:47 <rsalvaterra> *build system

09:48 <rsalvaterra> Well, turns out, it always takes KERNEL_PATCHVER as the reference.

09:49 <rsalvaterra> So, if you customise your testing kernel config, e.g. removing the aforementioned CONFIG_RTC_CLASS but leave it enabled in the KERNEL_PATCHVER's config, it will be enabled anyway.

09:50 <rsalvaterra> I don't know if it's worth to fix this, though. Someone hitting this issue is already so deep down the rabbit hole that probably had it coming. :P

09:54 <KGB-1> https://tests.reproducible-builds.org/openwrt/openwrt_kirkwood.html has been updated. (100.0% images and 99.9% packages reproducible in our current test framework.)

10:56 <KanjiMonster> rsalvaterra: I guess the issue is that probably everything scanning the kernel config would need to be taught the possibility of a testing kernel and then scan both and generate appropriate config.in

10:58 <KanjiMonster> which would then look like e.g ."FEATURES += rtc if CONFIG_RTC_CLASS=y && (TESTING_KERNEL=n || TESTING_KERNEL=y)" (and in your case one of the or:s would go away)

13:31 <f00b4r0> is it expected that ujail takes ~2.5M of RAM to run a service? This seems very high.

14:43 <Mangix> rmilecki: you maintain the upstream ubootenv driver AFAIK

14:44 <Mangix> rsalvaterra: unfortunate. IIRC all the clocks are intertwined and use multipliers. Guess one of them becomes too fast.

15:21 <dangole> rmilecki, Ansuel: has there ever been a debate or thought wasted on block devices or partitions acting as nvmem-providers? With devices booting from emmc this would a nice to have...

20:20 <rmilecki> Mangix: ah, I just followed link without reading your message, my bad

20:20 <rmilecki> Mangix: i don't know much / anything about urandom-seed, sorry

20:21 <rmilecki> Mangix: is there some U-Boot env variable that could help urandom-seed?

20:57 <Mangix> rmilecki: so my understanding is the kernel uses EFI variables on x86 to store a random seed. urandom-seed uses a file. all done in userspace of course. The efi thing seems like it's done in kernel space. Wonder if the same is possible for ubootenv

20:58 <Mangix> I don

20:59 <Mangix> 't speak kernel so that's why I ask.