**** BEGIN LOGGING AT Mon Sep 02 02:59:56 2019 Sep 02 06:01:21 abbradar: a better patch: https://paste.ubuntu.com/p/qWsv92jJCz/ Sep 02 06:12:10 Hauke: there's some open LuCI bugs I need to take care of the next few days Sep 02 06:15:16 bah, sysupgrade bricked my unifi ap ac pro :/ Sep 02 06:19:11 Sat Aug 31 22:35:18 2019 user.err kernel: [ 11.014059] mount_root: switching to jffs2 failed - fallback to ramoverlay Sep 02 06:19:27 Sat Aug 31 22:35:18 2019 kern.err kernel: [ 10.987329] jffs2: Too few erase blocks (3) Sep 02 06:21:09 I guess it's related to kernel 4.19 Sep 02 06:21:40 and make menuconfig is broken for me too Sep 02 06:24:10 /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: lxdialog/checklist.o: undefined reference to symbol 'keypad' Sep 02 06:24:10 /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /lib64/libtinfow.so.6: error adding symbols: DSO missing from command line Sep 02 06:24:26 https://www.spinics.net/lists/linux-kbuild/msg22662.html Sep 02 06:25:12 ah, https://bugs.openwrt.org/index.php?do=details&task_id=2423 Sep 02 06:29:25 except I have this on `make menuconfig` instead of make kernel_menuconfig Sep 02 06:42:42 gch981213: thanks, I'll try it later today! I also noticed that there is a firmware-only package in the tree (arm-trusted-firmware-sunxi) so I decided to package the bootloader this way too if upstream uboot works Sep 02 06:44:24 Ugh, just in case: is the message above readable for plain IRC users? Sep 02 06:50:14 Ugh, just in case: is the message above readable for plain IRC users?* (removed quoting) Sep 02 07:45:56 abbradar: seems yes Sep 02 07:46:33 mrkiko: good to know, thanks. Sep 02 07:46:35 hello guys! Sorry for my insistence in the ML but I was really curious as to what's going on on this device Sep 02 07:46:50 but I am running out of ideas Sep 02 08:53:12 when release v19.07 ? Sep 02 11:28:20 wth happened with kernel 4.19 that even an 8MB flash device is now too small for my AP image, even after removing all unneeded crypto kmods and iptables related stuff Sep 02 12:01:25 replacing tcpdump with tcpdump-mini results in a working image again Sep 02 12:02:06 would be nice if we could detect that an image is going to be too big during build, and fail to build the image at all instead of (soft-)bricking devices Sep 02 12:36:30 stintel: would be nice, but requires a bit more info for the build system than available for most devices (size of the firmware partition, erase block size) Sep 02 12:54:08 freetz can do that, too.... Sep 02 13:20:38 rubberduck: yeah but freez only supports a handful of devices Sep 02 13:20:45 (compared to openwrt that is) Sep 02 13:21:10 aren't the flash-sizes well-known for most openwrt devices? Sep 02 13:22:01 rubberduck: openwrt already does check for simple "file size too big" Sep 02 13:23:04 what is lacking is "file size minus kernel minus bootloader, minus whatever oem partition there might be is greater than three free erase blocks" Sep 02 13:23:20 problem is dynamic partitioning, partially unknown erase block size etc. Sep 02 13:27:51 and for extra fun there are devices sold with flash chips with different erase block sizes, so while the image might work with device a, it wouldn't with device b (although both take the same image) Sep 02 13:30:32 on the other hand there's always supported devices lacking stuff or being special Sep 02 13:30:43 what is worse is that I came home to a broken water pipe Sep 02 13:31:02 so far we always opted for the lowest common denominator, some opt-in mechanism for devices with known good properties should certainly be doable Sep 02 13:31:42 no water in my apartment, and the pipe broke off so I can't even temporarily fix it Sep 02 13:31:44 bah Sep 02 13:39:19 and of course the bricked unifi is the only device that has no automated backups and no recent manual one Sep 02 13:39:20 fml **** BEGIN LOGGING AT Mon Sep 02 16:04:30 2019 Sep 02 18:10:38 stintel: did you do some more analysis about the flash space increase Sep 02 18:11:00 jow: I would like to get the 19.07-rc1 out soon, so I would like to help Sep 02 18:11:06 but I have no experience with luci Sep 02 18:11:49 hello!!!!!!11 Sep 02 18:11:51 I am back! Sep 02 18:13:22 I am missing some gpio exported and I want them to control things... Sep 02 18:16:45 my board have gpio13 connected to plc, I am trying to control that gpio to turn on/off the plc, but I can´t see it as /sys/class/gpio/gpio13 Sep 02 18:17:03 Hauke: after replacing tcpdump with tcpdump-mini it's working again Sep 02 18:17:41 In /sys/kernel/debug/gpio I can see gpio-13 ( |PLC enable ) out hi Sep 02 18:19:41 How can I control it by command? (so I can script it...) Sep 02 18:22:47 another example would be gpio 21, to control wan power, and I can see "/sys/firmware/devicetree/base/ahb/apb/gpio@18040000/wlan_power", but I don´t know how to disable the wlan power Sep 02 18:23:23 stintel: I am more intrested in how much more space the kernel needs now Sep 02 18:23:44 if it is 1MB more we should definitly look into this problem Sep 02 18:24:06 if it is 20K, then it is probbaly spread over all parts of the kernel Sep 02 18:25:32 mrkiko: do you have a git tree somehwere I can have a look at Sep 02 18:29:10 Hauke: not the best comparison but my ar71xx vmlinux -> 5179556 vs ath79 vmlinux -> 5464920 Sep 02 18:29:15 don't have any other data right now Sep 02 18:32:44 maybe it's combined with wolfssl and tls1.3 or so Sep 02 18:42:59 but that is already a significant increase Sep 02 18:48:53 stintel: ath79 uses devicetree, which pulls in quite a bit of extra code (also some things are now done as proper drivers, pulling in more subsystems) Sep 02 19:11:38 i thought ath79 was more lean than ar71xx :-/ Sep 02 19:15:15 Hauke: please merge the generic patches Sep 02 19:15:18 jow: ping Sep 02 19:28:13 Borromini: I think people got tired of keeping things slim for 32/4 devices Sep 02 19:28:25 * hellsenberg has several ar71xx 32/4 devices :( Sep 02 19:31:37 Borromini: you still can use ath79 with a custom package selection Sep 02 21:08:16 Borromini: lean if you look at "less code that openwrt maintains" sure :) **** ENDING LOGGING AT Tue Sep 03 02:59:57 2019