**** BEGIN LOGGING AT Sun Jun 16 02:59:58 2019 Jun 16 03:30:14 hmm. meraki mr24 initramfs-kernel.bin magic number changed, can't boot 18.06.2 from u-boot Jun 16 03:57:52 somewhere between 5244-gf0c37f6ceb (first four bytes of initramfs-kernel.bin: 8e 73 ed 8a) and 6164-g9f5a4f8a42 (first four bytes of initramfs-kernel.bin: 27 05 19 56). u-boot rejects the latter. Jun 16 06:00:50 https://bugs.openwrt.org/index.php?do=details&task_id=2323 Jun 16 08:32:22 I'm a complete noob at IPv6. I've been reading the theory but confused about the practice. Should my LAN interface have an IP address like in IPv4? At the moment I appear to only have a "prefix". I thought that was just a network like 192.168.1.0/24. Shouldn't I also have a LAN IP on said subnet? Jun 16 08:40:23 by (OpenWrt) default you should have two local IPv6 addresses (plus privacy extensions, if your clients desire), a link-local address (fe80::/10) and an address out of your ULA prefix (fc00::/7) Jun 16 08:40:43 plus a globabally routable address, if provided by your ISP Jun 16 08:42:06 (read, you should normally (incl. privacy extensions) have seven IPv6 in total, temporarily more after your current privext assignments expire) Jun 16 08:43:29 pkgadd, thanks. Do I have two globally routable addresses? One for WAN and one for LAN. Jun 16 08:44:05 yes (with privext)/ no Jun 16 08:44:26 I've currently got two IP addresses on my LAN, one global scope and one link. The link has scope 64 and global 60 Jun 16 08:44:42 Ok great, I'll go research privext as I don't know what that is right now Jun 16 08:44:48 thanks for giving me a nudge in the right direction Jun 16 08:44:50 Neighbor11111117: does your ISP provision ipv6 to you? Jun 16 08:45:29 russell--, sorry to be annoying but I don't know that. The reason I'm looking into this is I'm getting a few bugs with IPv6 on my client devices Jun 16 08:45:46 I can tell because wireshark has IPv6 addresses for packets with the problem Jun 16 08:46:18 what are the first couple bytes of your ipv6 addr? Jun 16 08:46:43 the LAN one? Jun 16 08:46:50 either, actually Jun 16 08:46:53 or both Jun 16 08:47:14 on LAN I've got fe80 for link and fd23 for global Jun 16 08:47:29 and WAN global is 2002 Jun 16 08:47:36 link fe80 Jun 16 08:48:10 brb (5 mins or so, sorry its urgent) Jun 16 08:48:31 that looks like the ISP is giving you a WAN address, but not giving you an allocation Jun 16 08:48:41 ... for your LAN Jun 16 08:49:54 fdxx is a private address Jun 16 08:52:18 Neighbor11111117: also, this is more of an #openwrt channel question Jun 16 08:54:50 Yeah sorry russell-- I typically ask developer questions. I'll shoot over there and ask :) Jun 16 08:56:18 before I go russell--, one quick question please. How does the router get it's "allocation" from the ISP? Is it via DHCPv6? Jun 16 08:56:39 I should say typically Jun 16 08:56:51 there are several ways Jun 16 08:56:59 i'll talk to you over there Jun 16 08:57:11 ok great catch you there thanks Jun 16 10:50:52 dedeckeh: pong Jun 16 10:53:57 Hauke:I was wondering why !LINUX_4.9 needed to be added in patch http://patchwork.ozlabs.org/patch/1115916/ Jun 16 10:54:29 as I thought we will switch all targets to 4.19 in master Jun 16 11:00:51 dedeckeh: that depends on targets supporting 4.19; until that happens we still need to support older kernel versions Jun 16 11:04:49 KanjiMonster:Ok I see there are still a few targets on 4.9 like ar7, ixp4xx, orion Jun 16 11:16:35 dedeckeh: there are still these 3 targets on kernel 4.9 Jun 16 11:16:48 in openwrt 19.07 these targets were removed Jun 16 11:17:13 I also would like to remove kernel 4.9 support for master soon Jun 16 11:28:13 Hauke: thx Jun 16 14:02:32 ynezz: GCC 9.1 complains about urngd, should I make a pull request or how do you like contributions? Jun 16 14:02:52 Hauke: how much would automatic testing simplify the workflow of back porting stuff to older kernels and keeping them alive.? Jun 16 14:04:27 aparcar[m]: it would be really nice if we can check that devices still work Jun 16 14:04:47 to hard part is not to break things taht worked before Jun 16 14:16:59 KanjiMonster: could you please check https://github.com/openwrt/openwrt/pull/2124 again? I'm very new to Makefiles... Jun 16 14:34:44 My old but trusty wndr3700v2 sadly has died. I am looking for a replacement, requirements dual band wifi, vlan capable switch, external modem. I have narrowed it down to Linksys WRT3200ACM,EA8300 or netgear r8000. Comments/suggestions please. Jun 16 15:57:47 pepe Jun 16 15:58:49 pepe2k: isn't it enough to check include/kernel-version.mk to see if a kernel was upgraded? Meaning to trigger a kernel build plus all modules only when that changed Jun 16 16:01:38 aparcar[m]: you also have to recompile the kernel when some configurations changed Jun 16 16:01:51 aparcar[m]: there might be some config changes withing (sub)targets Jun 16 16:02:17 and patches, drivers, etc. updates Jun 16 16:07:45 Where to be found? Jun 16 16:07:55 never touch anything kernel related Jun 16 16:10:08 aparcar[m]: target/linux/*/files/, target/linux/*/patches-*, target/linux/*/config-* and in case there are subtargets, look also in subaterget folders for config-default Jun 16 16:15:48 is it likely that multiple targets change within a single commit? Jun 16 16:19:19 yes Jun 16 16:23:50 okay thanks Jun 16 17:55:07 updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html Jun 16 18:10:04 Who's the maintainer of uhttpd? Jun 16 18:11:14 never mind, I found it on the Makefile, is Felix Jun 16 18:11:40 nbd: I just found an issue when compiling from master Jun 16 18:11:53 After the following commit of libubox (and the update on master), uhttpd is not compiling. Jun 16 18:11:54 ustream: Add format string checks to ustream_(v)printf() Jun 16 18:13:02 It has 2 warnings (treated as errors) on utils.c. The first one is: Jun 16 18:13:03 utils.c:50:26: error: too many arguments for format [-Werror=format-extra-args] Jun 16 18:13:03 ustream_printf(cl->us, "\r\n", len); Jun 16 18:13:49 I don't know what's the intent of the code, so I didn't send a patch Jun 16 18:14:12 I think it's: ustream_printf(cl->us, "\r\n"); Jun 16 18:14:13 but it could also be: ustream_printf(cl->us, "%X\r\n", len); Jun 16 18:33:25 Hauke: ideally we should move urngd under git.openwrt.org Jun 16 18:35:22 as a temporary workaround I can add you (or anybody else) as a contributor to that repo Jun 16 18:40:40 rmilecki: I've noticed, that you've added 4.19 support to brcm47xx, unfortunately it doesn't compile due to broadcom-wl-5.10.56.27.3/driver/wl_linux.c:2576:2: error: implicit declaration of function 'init_timer' Jun 16 18:42:16 nbd: uhttpd has similar errors on the following files: proc.c:235, ubus.c:146, ubus.c:150 Jun 16 18:43:00 rmilecki: probably something has changed during the 4.19 kernel bumps (or such), but as I don't have any brcm47xx device I'm not comfortable enough to just compile fix it Jun 16 18:43:59 rmilecki: and due to your note `This IS NOT ready for switching/trying/using 4.19 yet due to some DMA`, I'll leave it on 4.14 until someone can actually verify latest 4.19 on device Jun 16 18:47:28 luaraneda: yeah, it's very likely, that this new format string checking is going to break a lot of downstream projects using libubox, so patches are welcome :) Jun 16 18:49:35 ynezz: nbd: This fixes uhttpd compilation, but I don't know if the semantic is ok: https://pastebin.com/LLH4Q2DG Jun 16 18:51:04 if you are git bisecting, but the tool chain is fine, what is a good make clean target to use between builds? Jun 16 18:55:06 luaraneda: no, i think you simply need to remove the len argument instead Jun 16 18:55:19 it was a copy&paste bug Jun 16 18:58:14 nbd: ok, would you fix them? It's so easy to fix and I think that I would waste more time generating and sending a patch Jun 16 18:59:25 nbd: You can use https://pastebin.com/LLH4Q2DG as a starting point :) Jun 16 19:03:05 ynezz: i forgot about that ssb/DMA issue, thanks for remainding Jun 16 19:03:14 ynezz: i have ER-X that is mt7621 Jun 16 19:09:52 rmilecki: yep, considering ER-X as well, since I might replace one dumb switch I've here with ER-X and then it might be my daily driver Jun 16 19:18:52 Hauke: have 4.19 switch ready and compile tested on almost everything https://pad.riseup.net/p/openwrt-4.19 do you've any objections regarding 4.19 fixes in my staging tree? Jun 16 19:19:44 (I'm not sure if I've missed anything here on IRC) Jun 16 19:20:50 ynezz: you can also look at ER-X-SFP, this gives you an extra SFP/ethernet port. Jun 16 19:21:45 well, it's not worth the extra $ :) Jun 16 19:22:42 ynezz: re: tegra config refresh; should CONFIG_CC_HAS_ASM_GOTO be in target config? Jun 16 19:27:05 it doesn't look like generic option Jun 16 19:27:55 or you mean, I should remove it from the refresh completly and let the compiler decide? Jun 16 19:29:40 yeah, I think this should be decided dynamically, but am no expert in this :) Jun 16 19:30:31 makes sense, good point Jun 16 19:37:42 rmilecki: BTW `bcm53xx: disable images for Archers c5v2 and c9v1` as 4.19 leads to `os-image partition too big (more than 2097152 bytes): Success` Jun 16 19:39:17 Hauke: lynxis: is someone already working on the final summary from the Hamburg meetup? Jun 16 19:39:35 ynezz: ? is there some problem? is there such a patch? Jun 16 19:39:39 ynezz: i'm missing some background Jun 16 19:40:41 ynezz: disabling images results in error that is summarized as a Success? Jun 16 19:40:46 i don't get it Jun 16 19:40:48 pepe2k: I hopefully meet lynxis tomorrow and suggest to work on it Jun 16 19:41:22 rmilecki: preparing 4.19 switch https://pad.riseup.net/p/openwrt-4.19 and bcm53xx didn't pass build test so I had to disable those two boards to fix it Jun 16 19:41:35 rmilecki: indeed, that error is quite misleading :) Jun 16 19:42:23 ynezz: please don't disable images for those devices Jun 16 19:42:30 I can handle bcm53xx properly if needed Jun 16 19:42:33 rmilecki: that's the patch https://git.openwrt.org/df2a197c0f12 Jun 16 19:42:52 ynezz: i see, but honestly, I don't want it Jun 16 19:43:01 let's fix things before switching bcm53xx to 4.19, that's it Jun 16 19:43:16 it won't hurt to leave it at 4.19 for few more weeks if needed Jun 16 19:43:29 ok, fine with me, so just don't swtich bcm53xx to 4.19 yet? Jun 16 19:43:43 yes, please Jun 16 19:52:21 ynezz: are you working on the openwrt.git/packages review? Jun 16 19:53:25 aparcar[m]: what do you mean exactly? Jun 16 19:54:41 * aparcar[m] sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/yhJIyQSSnqljsjAyzgFYZtal > Jun 16 19:55:37 I'm not going to click on random links from matrix universe :) Jun 16 19:56:09 Sorry I don't know how it looks in plain IRC Jun 16 19:56:10 * aparcar[m] sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/UbpkGyheJhqorVHDsCrPMBbt > Jun 16 19:56:15 I quoted your mail Jun 16 19:57:15 https://paste.ubuntu.com/p/XRSD2CSdMD/ Jun 16 19:57:26 it looks like this in our universe :) Jun 16 19:58:05 https://paste.ubuntu.com/p/DDN3CTCjnj/ Jun 16 19:59:48 aparcar[m]: that's my e-mail :) Jun 16 20:00:04 petr or piotr, it sounds same :) Jun 16 20:00:18 and actually means the same :) Jun 16 20:02:51 Ynezz, because irc and long messages are a not thing.. and yes I know splitlong, but once upon a time ircers cried matrix user giving gazillion me.long messages so they decided this method, with some default triggers that I don't remember offhand... there is no pleasing the old.grey beard ;) Jun 16 20:03:21 yeah, lets talk over pastebins instead Jun 16 20:04:40 "Just a side note here. During the meetup in Hamburg we discussed about having only the required and actually "basic" packages inside the master tree and move everything else to packages feed (after reviewing what's there)." Jun 16 20:04:41 Or chat stuff that doesn't suck as much :p Jun 16 20:05:13 pepe2k: ynezz sorry guys! I owe you a beer I guess Jun 16 20:05:29 I really miss what's wrong with that message, that it must be shared over some matrix.org crap Jun 16 20:05:50 aparcar[m]: np! Jun 16 20:06:00 ynezz: too long? Jun 16 20:06:14 as you can see my irssi just handle it fine Jun 16 20:06:30 It was a quote Jun 16 20:06:56 I think that was a rootissue Jun 16 20:08:44 it's offtopic, but the root issue is something else :) Jun 16 20:09:00 I should consider switching to some plain IRC client, Jun 16 20:09:45 ynezz: it's sunday so offtopic seems reasonable Jun 16 20:10:15 I dunno why it says "long message" as reason.. and yes I too realise things will never be 100% compatible between any 2 diffirent medias, but we can always improve Jun 16 20:12:51 yeah, happy we don't have any Slack bridge (yet) Jun 16 20:13:32 Inherent problem is that matrix has okayish quote system among "no size limit" message length... bridge have to do something if matrix client tries use such blasphemy ;) Jun 16 20:15:09 More offtopic.. at few channels we bridge slack channel to matrix channel.. with telegram and irc... I have to say it does behave suprisingly good for every medias users Jun 16 20:17:45 ..if there is inclination to talk more about this sort of OT, for funsies or learning or otherwise, we can.. private or new channel :) end of matrix OT from me in here unless wanted more :) Jun 16 20:19:41 `Backport generated by backports.git v4.19.32-1-0-g1c4f7569` looks really weird on 4.19.50 :) Jun 16 20:20:19 luaraneda: will you send a patch to fix this? Jun 16 20:20:31 otherwise I will look it this myself Jun 16 20:22:32 ynezz: I plan to do a new 5.2 release and then I will also update the older versions Jun 16 20:30:19 oh, so it would be possible to run 5.2 backports on 4.19? Jun 16 20:34:35 ynezz: yes, currently the most recent version is backport 5.1 I already have a branch in my staging tree with that Jun 16 20:35:00 I think Daniel is working on some fixes which are needed for backports 5.2 Jun 16 20:35:08 ah, nice Jun 16 20:39:26 rmilecki: the build bnot found a problem in brcmfmac: brcm80211/brcmfmac/dmi.c:60:20: error: 'DMI_PRODUCT_SKU' undeclared here (not in a function); did you mean 'DMI_PRODUCT_UUID'? Jun 16 20:39:31 http://phase1.builds.openwrt.org/builders/x86%2Fgeode/builds/1415/steps/pkgbuild/logs/stdio Jun 16 20:39:44 oh my, sorry Jun 16 20:39:46 I'll fix that Jun 16 20:39:52 rmilecki: thanks Jun 16 20:40:00 i used wrong .config Jun 16 20:40:48 I broke the same build with a different problem ;-) Jun 16 20:51:42 Hauke: I just run-tested this patch for uhttpd: https://pastebin.com/6VR45rJR Jun 16 20:51:42 I'm a little busy right now to send a patch. Feel free to use it to create your own patch Jun 16 20:59:06 luaraneda: it is fixed now Jun 16 20:59:18 pepe2k: so, you look into the package move of openwrt.git? sorry for the delay Jun 16 21:03:44 aparcar[m]: no, my mail was only about the new package from Christian Jun 16 21:06:15 ok Jun 16 21:11:26 lol, git bisect: "Build dependency: Please install the GNU C Compiler (gcc) 4.8 or later cc -dumpversion | grep -E '(4\.[8-9]|5\.?[0-9]?|6\.?[0-9]?|7\.?[0-9]?)'" Jun 16 21:11:56 $ cc -dumpversion Jun 16 21:11:57 8.3.0 Jun 16 21:13:01 ynezz: I added a patch for urngd, but it would be nice if we can move it to git.openwrt.org, probably jow can help you with that Jun 16 21:14:56 russell-- so looks like time for more regex ors ;) Jun 16 21:20:58 ynezz: I would let each target maintainer switch to 4.19 individually, they can do it if they think it is stable enough Jun 16 21:22:43 oh, on brcm47xx i can select CONFIG_BRCMFMAC_SDIO=y but it seems SDIO doesn't get compiled anyway Jun 16 21:22:54 ynezz: I think the KERNEL_TESTING_PATCHVER can be removed when you switch to 4.19 Jun 16 21:23:26 rmilecki: I am not aware of any brcm47xx device using brcmfmac with SDIO Jun 16 21:23:34 right Jun 16 21:23:41 but i was using brcm47xx for compile test Jun 16 21:26:25 oh, after make V=s it seems sdio.c gets compiled, it was using make package/kernel/mac80211/compile V=s previosly Jun 16 21:26:36 Hauke: is that build for master for 19.07 or sth els? Jun 16 21:28:43 ah, it's not SDIO specific, but DMI specific Jun 16 21:29:07 maybe it requires build on platform with ACPI Jun 16 21:30:52 I think this is master, but this is x86 so with ACPI Jun 16 21:31:11 olmari: can't fix git history, so a new change doesn't help for bisect. looks like i need to install a local gcc7. Jun 16 21:41:11 some symlinks seemed to do the trick Jun 16 21:43:31 Hauke: i started x86 target compilation, i'm going slee now, I'll get that fixed tomorrow Jun 16 21:43:41 compilation will probably take me 1-2 hours Jun 16 21:43:51 so I won't be waiting for that today Jun 16 21:47:34 rmilecki: ok Jun 16 21:51:24 what is the package called ead in openwrt.git/package/network/services/ead? Jun 16 21:51:26 tmn505_: is CONFIG_NET_DSA_LEGACY needed for mvebu with kernel 4.19? Jun 16 21:52:30 neoraider: did you bump libjson-c? Jun 16 21:56:44 ynezz: tmn505_: the mvebu 4.19 patches are looking good to me Jun 16 21:57:25 some explanation about the sfp patches in the openwrt patch descripotion would be nice, like the source where they are from Jun 16 22:05:31 aparcar[m]: ah, I completely forgot about that, thanks for the reminder Jun 16 22:05:42 aparcar[m]: will take care of that tomorrow Jun 16 22:44:58 is the TARGET_INIT_ENV still supported? can't find where pi_init_env is being used/exported Jun 16 23:16:26 * russell-- tries on a machine with older tools **** ENDING LOGGING AT Mon Jun 17 02:59:57 2019