**** BEGIN LOGGING AT Wed Mar 13 02:59:57 2019 Mar 13 10:35:32 I think what happens is something like "Isn't C supposed to be complicated....oh my god look at all those brackets.... EBRACKETOVERLOAD brain fried core dumped" Mar 13 11:09:18 parens++ Mar 13 12:19:55 common lisp ftw Mar 13 12:46:09 hello Mar 13 12:46:33 how is one supposed to express a dependency between a host tool in tools/ and a host library such as package/libs/libjson-c/ ? Mar 13 12:46:53 in tools/Makefile, I see how tools/ can describe a dependency on tools/, but not on package/libs/ Mar 13 16:09:57 lach1012: just saw You pushed my epg5000 patch, unfortunately the old mach file was correct about the leds, will send a fix in half hour with some migration scripts. Mar 13 16:10:12 tmn505, +1 Mar 13 16:43:27 lach1012: fix sent, thanks. Mar 13 16:51:09 tmn505: thanks for starting with this ar71xx->ath79 migrations, yet I'm wondering if we need to continue with this copy&pasta based solutions Mar 13 16:52:51 ynezz: do you want to take this over? Mar 13 16:55:40 ynezz: np, do You have something other in mind how to implement that? Mar 13 16:57:37 tmn505: I've just looked at your LED migration scripts and looked up `do_led_update_sysfs` in the source tree, seems like it's very similar to others and could be shared in base-files/lib/functions/leds.sh for example, instead of copy&pasted from platform to platform Mar 13 16:58:27 what do you think? Mar 13 16:58:37 lantiq and ar71xx? Mar 13 16:59:21 yes, I believe, that LEDs are handled in similar way, so the migrations could be shared, or am I mistaken? Mar 13 17:00:13 but maybe I'm just sensitive to this code duplication :) Mar 13 17:02:19 do_led_update_sysfs modifies a file local variable though Mar 13 17:03:42 hmm, that could work. Mar 13 17:04:15 do you think you can get rid of the LED_OPTIONS_CHANGED=1 ? Mar 13 17:05:23 probably by returning some value from do_led_update_sysfs instead of this global? Mar 13 17:06:36 hm, this won't work in the config_foreach loop Mar 13 17:08:42 anyway, LED_OPTIONS_CHANGED=1 is used just to do `uci commit system` and this could be done better probably Mar 13 17:10:05 well, we would like to avoid running uci commit system on every boot Mar 13 17:10:10 or for every LED Mar 13 17:10:49 it's called just once after upgrade, it's in uci-defaults Mar 13 17:11:31 just call `uci commit system` once in the end (if nothing has changed it should be noop anyway) Mar 13 17:12:31 or there could be something to check for LEDs with `uci changes` and handle it with commit Mar 13 17:13:23 kids are calling, bbl Mar 13 17:24:57 any python gurus around ? Mar 13 17:24:58 ImportError: No module named attr Mar 13 17:25:09 happens when i build wirelessreg-db in 18.06.2 Mar 13 17:43:43 blogic, ooh can you install python-future on the builders? Mar 13 17:46:30 and you are probably looking for a package: python-attr Mar 13 17:48:16 blogic: I build my own wirelessreg-db and I don't remember this issue I installed this dependencies in debian stable https://gitlab.com/guifi-exo/temba/blob/master/install_temba_cli.sh try `pip install attr` ? Mar 13 17:50:23 its pip install attrs and not attr Mar 13 17:50:30 thats the curlpit Mar 13 17:50:35 python is the new java Mar 13 17:51:42 installing attr works but blows up differently Mar 13 17:51:53 because attrs and attr register the same namespace Mar 13 18:16:05 Has anyone here run into the UBIFS image generated by two ".bin" IMAGES being different, during the same `make` run? Mar 13 18:17:20 (in my case, one boots, the other is considered corrupt, same file-system tree for both) Mar 13 18:28:40 + IMAGE/combined.bin := append-kernel | pad-to $$$${KERNEL_SIZE} | append-ubi Mar 13 18:28:41 + IMAGE/combined2.bin := append-kernel | pad-to $$$${KERNEL_SIZE} | append-ubi Mar 13 18:28:54 $ md5sum *.bin Mar 13 18:28:54 935a7765bacca6a8ab6a208b5793c96e OpenWrt-2019-03-13_1118-0700-ipq40xx-linksys_ea8300-squashfs-combined2.bin Mar 13 18:28:54 eaa7b60439b3741411ee9df554db7a04 OpenWrt-2019-03-13_1118-0700-ipq40xx-linksys_ea8300-squashfs-combined.bin Mar 13 18:30:03 Some there isn't repeatable! Mar 13 19:03:35 blogic: do you want to upgrade wireless-regdb? Mar 13 19:03:45 I had a look at it and gave it up ;-) Mar 13 19:05:37 Which fd does the build system re-bind for stdout? Mar 13 19:26:11 jeffsf, I had mksquashfs messing up. It build a rootfs image that could not be read by either the kernel or unsquashfs Mar 13 19:27:58 It looks like the squashfs contents are the same, from the same build_dir/.../root.squashfs, but the EC headers on the PEBs are different in the `padding2` field. Mar 13 19:29:39 append-ubi step calls `scripts/ubinize-image.sh` each time, wiping the generated @.tmp each time Mar 13 19:30:24 I'm surprised to see anything but zeros in padding2, but looking into `drivers/mtd/ubi/ubi-media.h` next to see what I might be missing Mar 13 19:34:38 Ah -- update since the spec I was working with -- `padding2` was "revised" from 36 bytes to 4 bytes of `image_seq` and 32 bytes of `padding2` Mar 13 19:35:17 it is the image_seq that is changing, which apparently allows for detection of partial re-flashes Mar 13 19:35:43 (The EC headers would change image_seq past the point of a failed flash) Mar 13 19:36:41 Which potentially explains why the checks fail with the Linksys trailer, but not without it. Mar 13 19:39:01 An interesting challenge for "repeatable builds" for UBI-based devices! Mar 13 19:52:28 tmn505, lach1012: http://paste.ubuntu.com/p/JYJ4Dc4GfW/ I've meant something like this, untested Mar 13 19:54:17 I wouldn't touch ar71xx/lantiq at this moment, it can be done later - I've included it as an example for reusable migrations.sh which could be used in ath79 for a start Mar 13 20:05:38 and I think that having `migrations_apply system` is overkill as just doing `uci commit system` would be enough as commit without changes (no delta) is probably noop https://lxr.openwrt.org/source/uci/file.c#L744 Mar 13 20:24:01 ynezz: +1 Mar 13 21:04:07 ynezz: thanks, that looks good, I'll give it a test tomorrow. Mar 13 22:21:11 Is there a "pad-to-at-least" function in building images ("make sure this is at least NNN long")? `pad-to` won't work as it implements using `bs` in `dd` Mar 13 22:35:03 jeffsf, what do the boot failures look like? Mar 13 22:35:17 [ 1.938966] ubi0 warning: ubi_attach: valid VID header but corrupted EC header at PEB 31 Mar 13 22:35:31 hm Mar 13 22:35:37 is the NAND bad at that location? Mar 13 22:35:51 ... or Mar 13 22:35:56 If the flashed image is "too small" (somewhere around 42 PEBs), then it scans into the "signature" factory trailer Mar 13 22:36:07 can you use the userspace ubireader to extract the files from the image? Mar 13 22:36:12 NAND has been checked -- problem is that it "runs off the end" Mar 13 22:36:23 Image is good Mar 13 22:36:48 It's as if the UBI validator doesn't know to "stop" Mar 13 22:37:06 but somehow, "magically" stops after 43 or so PEBs Mar 13 22:37:14 it should run into the mtd partition size limit?! Mar 13 22:37:38 There's a trailer at the end of the factory image that gets "ignored" if it's "far enough" out Mar 13 22:38:32 a full page of 0s won't stop it Mar 13 22:38:46 have you checked if the vendor firmware writes the complete image? Mar 13 22:39:01 or is it confused by something (i.e. a jffs2 end marker) Mar 13 22:39:26 Images work OK if they are "big enough" -- I only discovered it when I removed all the kernel/80211mac tracing Mar 13 22:39:49 (and all my "diagnostic" packages) Mar 13 22:41:26 PEB 31 in that case was the start of the appended header. Just strange that if it's far enough out it doesn't cause a problem Mar 13 22:41:45 hm Mar 13 22:41:50 you could play with the UBINIZE_OPTS := -E 5 Mar 13 22:42:00 Hmm, OK, I'll look into that Mar 13 22:42:01 I think you could add more Mar 13 22:43:11 zero-padding isn't helping; 4096 k pushes the error out to PEB 55, and 0xff padding is "annoying" without /dev/one Mar 13 22:44:23 `-E 5` ? I dont see that on Debian `man ubinize` Mar 13 22:44:49 I think it's openwrt specific Mar 13 22:44:56 OK Mar 13 22:45:04 tools/mtd-utils/patches/201-ubinize-add-terminator-support.patch 0 → 100644 Mar 13 22:45:13 thunbs up! Mar 13 22:46:06 so in a way you are padding the image ;) Mar 13 22:46:54 I just need to shout "Jane! Stop this crazy thing!" Mar 13 22:50:56 Is there somthing "magic" about 5 markers? Mar 13 22:51:40 do you need more? Mar 13 22:53:20 No, hate to waste bytes, even on a "big" flash. Can't help but remember ... ; HLT ; JMP -1 Mar 13 22:55:31 waste bytes? Mar 13 22:55:37 on the flash, or image? Mar 13 22:55:47 Wouldn't one be enough? Mar 13 22:56:04 I'll go with 5... Mar 13 22:56:14 On the image size Mar 13 22:56:24 I know -- too much time with 16 kB MPUs Mar 13 23:04:43 thanks lach1012: [ 1.929990] UBI: EOF marker found, PEBs from 23 will be erased Mar 13 23:04:55 I think the error happens Mar 13 23:06:14 Now seen in the image |UBI#.EOF........| Mar 13 23:06:16 because the ubi image we upload/flash is not the full length (because that bloat the images and do needless erase + writes) Mar 13 23:06:42 if you do ubiformat from a initramfs image you can mitigate this step Mar 13 23:07:09 but since you are gunning for a factory.bin that's probably not a option Mar 13 23:07:18 Yes, that makes sense. Just trying to get this thing bootable from OEM into OpenWrt without the user having to jump through hoops Mar 13 23:07:37 well, having a factory.bin is not required Mar 13 23:08:10 as long as the flashing instructions are understandable it's all just fine Mar 13 23:08:16 I haven't found a hole in the OEM web interface to get access to another option (yet) Mar 13 23:08:31 nah, u-boot! Mar 13 23:08:39 "Crack the case, solder a 3.3 V serial adapter, ..." Mar 13 23:08:44 yes yes yes Mar 13 23:08:49 but Mar 13 23:09:07 instead of soldering a serial adapter, I just solder 1x3 or 1x4 pin-headers Mar 13 23:09:34 and as a bonus: you can use these "flashing through u-boot" instructions for debricking Mar 13 23:09:47 My desk looks like Medusa's hair, with three different devices in pieces hooked up already Mar 13 23:10:06 I think I added the glint? Mar 13 23:10:15 so you could move it elsewhere Mar 13 23:10:27 Between the serial leads and two Ethernet cables on each Mar 13 23:10:56 my MR33 looks like that Mar 13 23:11:09 except it only has one lan port Mar 13 23:11:26 but the power-cable is attached to the same side next to the lan port Mar 13 23:11:37 At least the EA8300 has big ventilation holes in the top, perfect for 24 ga wires ;) Mar 13 23:11:54 I just drill through the plastic Mar 13 23:11:58 don't care anymore Mar 13 23:12:12 it's not like I want to sell them, usually when they leave the devices are dead Mar 13 23:12:17 LOL, yeah, my bench Archer C7 has the adapter glued into the case Mar 13 23:12:26 plug-n-go Mar 13 23:14:27 OK, thanks for solving that problem -- was killing me that a "too small" kernel (or so I thought) would cause a device to fail to boot Mar 13 23:15:09 Now I'm just down to the gremlins in U-Boot Mar 13 23:15:31 Running smoothly on 4.19 with the DSA patches Mar 13 23:15:38 oh Mar 13 23:15:44 I do have some updates for that Mar 13 23:16:03 OK, I'm using a half-dozen or so from the openwrt/staging tree Mar 13 23:16:16 yeah, be prepared to swap them out Mar 13 23:16:35 I'm getting goot at `git rebase --onto` these days Mar 13 23:17:22 I figured I wasn't going to "make" the v19 branch, so might as well get onto 4.19 and DSA rather than try to transition later Mar 13 23:17:56 oh, dsa will not happen right away Mar 13 23:18:10 I promised john to have a version that can be tested Mar 13 23:18:30 especially because I don't have the tools to check PPPoE Mar 13 23:18:48 I don't either, unfortunately Mar 13 23:18:48 and other weird dailup protocols Mar 13 23:18:53 LOL, yeah Mar 13 23:18:53 or iptv Mar 13 23:18:58 or igmp Mar 13 23:19:02 stp Mar 13 23:19:04 PPPoE over QinQ Mar 13 23:19:04 etc Mar 13 23:19:40 QinQ! Mar 13 23:19:48 but that should work now I think Mar 13 23:20:23 oh and QoS Mar 13 23:21:11 At least for the way I think, being able to control the switch at the level of ingress restrictions and the like will be an advantage Mar 13 23:21:35 well, you read the QCA8337 paper Mar 13 23:21:43 the builtin switch could do more Mar 13 23:22:09 Yes, tantalizing Mar 13 23:22:41 and buggy Mar 13 23:22:56 I was glad that 284 pages or so were repetitive tables! Mar 13 23:23:26 the register files? Mar 13 23:23:56 Yeah Mar 13 23:26:46 btw, thanks for all the help Mar 13 23:26:52 I think this is done to keep the eye-strain down 🤪 Mar 13 23:27:31 yea, I'm signing off for today Mar 13 23:27:41 Have a great night Mar 13 23:27:48 you too Mar 13 23:28:31 hey, that sounds good :) Mar 14 01:32:03 Rene__: ping **** ENDING LOGGING AT Thu Mar 14 02:59:57 2019