**** BEGIN LOGGING AT Thu Aug 01 03:00:25 2019 Aug 01 05:51:33 Hi and good morning people! Aug 01 05:51:52 I am trying to build and my build keeps breacking at building scons Aug 01 05:52:06 breaking* Aug 01 05:52:12 please no more scons! Aug 01 05:52:22 :) Aug 01 05:52:36 would you like a cuppa tea with that scone Aug 01 05:52:49 yes pleas! Aug 01 05:52:55 Jam and creem Aug 01 05:53:05 yum Aug 01 05:54:06 When I was in cornwall last year I ate a bot load of them I swear I put on about 10 LB in a week! :) Aug 01 05:54:29 boat* Aug 01 05:54:30 Tapper: if you're getting `ModuleNotFoundError: No module named 'distutils.command'` then you need to do `sudo apt-get install python3-distutils` or equivalent for your distro Aug 01 05:54:33 when i lived in scotland they were part of my diet Aug 01 05:55:08 in the usa we usually call them biscuits Aug 01 05:55:50 ynezz thanks mate will let you know if that works in a min. Aug 01 05:56:12 blogic lol at leest it was not buckfast! :) Aug 01 05:56:48 tear down the house juice, buckfast is pure evil Aug 01 05:56:57 DonkeyHotei in the UK we have dried fruit in them! Aug 01 05:57:09 we have that here Aug 01 05:57:11 DonkeyHotei some times cheese! Aug 01 05:57:17 DonkeyHotei: scones is not a biscuit Aug 01 05:57:25 its a small cake Aug 01 05:57:43 blogic O what have i started lol Aug 01 05:57:55 sorry, i'll stop Aug 01 05:58:09 * Tapper Tapper gos back to drinking his coffee Aug 01 05:58:27 lol Aug 01 05:58:52 I need to look up the recipe now to check! Aug 01 06:01:26 https://www.quora.com/What-is-the-difference-between-a-British-scone-and-an-American-biscuit Aug 01 06:02:41 I kicked off a new build so we will see. Aug 01 06:04:20 `make tools/scons/{clean,compile}` should be enough Aug 01 06:05:01 In other food news I have just found this I am going to try out. https://healthiersteps.com/recipe/butternut-squash-coconut-curry/ Aug 01 06:05:29 ynezz thanks mate It looks like it is working now. Aug 01 06:57:23 ynezz: regarding your EAP question see https://patchwork.ozlabs.org/patch/884518/ Aug 01 06:59:52 ynezz: see also this recent e-mail from Etienne http://lists.infradead.org/pipermail/openwrt-devel/2019-July/018136.html Aug 01 07:00:08 that issue pointed by nbd should be debugged properly & fixed properly Aug 01 07:00:33 that specific "The failure case involved a client roaming between multiple access points." case Aug 01 07:07:34 rmilecki: thanks, I would simply remove that hack from 4.19 Aug 01 07:08:03 or make it a config option with other hack patches Aug 01 07:09:52 nbd: please comment on that Aug 01 07:10:08 nbd: can you look at the original problem & suggest any better solution Aug 01 07:10:26 ynezz: let's just give nbd a chance to look at that Aug 01 07:10:36 see if he checks that / replies in some reasonable time Aug 01 07:12:39 see for example another one https://github.com/openwrt/openwrt/pull/2039 Aug 01 07:13:44 I'm not in a hurry or facing any of this issues, but it would be nice to get this sorted out for next release :) Aug 01 07:14:06 ynezz: i agree Aug 01 07:14:47 if we need that rtcache stuff, then it should be runtime configurable and disabled by default Aug 01 07:22:03 ynezz: there are a lot of users ready to kill for fast NAT Aug 01 07:22:12 ynezz: so we probably should keep it somehow Aug 01 07:23:43 and some users care for security and stability Aug 01 07:25:45 hard decision, but I would prefer secure and stable by default and let there be some knob(s) for optimizations Aug 01 07:50:01 how does rtcache relate to flow offloading? Aug 01 07:50:41 iirc that rtcache was reintroduced because nat performance started to nosedive after upstream removed caching Aug 01 07:51:03 if flow offloading can compansate for that I'd be fine to drop the rtcache Aug 01 07:51:21 (flow offloading allegedly is broken on 4.19 too, but thats another story) Aug 01 07:55:03 * ldir doesn't believe in this sort of voodoo - get a faster processor ;-) Aug 01 07:56:48 me neither, but the main userbase is still people using weak SoCs Aug 01 07:56:57 I found flow-offloading affected sqm in undesirable (for me) ways. For example DSCP mangling. Aug 01 07:57:13 even if some people make it look as if mvebu arm crap is all that is relevant today Aug 01 07:58:47 I've offloaded all the wireless stuff to wireless boxes. routing is done by a routing box. Aug 01 08:00:28 ynezz: what PR ? Aug 01 08:02:32 perhaps one option could be to make rtcache an easy opt-in, for example via a sysctl, for one release cycle and then remove in the next cycle if noone complains Aug 01 08:03:30 like ldir, flow offloading has some undesirable effects in some of my configurations Aug 01 08:04:29 kristrev: can you tell me the effects ? Aug 01 08:04:44 ldir: and could you do so aswell, ideally in a mail with the details ? Aug 01 08:04:55 I am working with pablo right now to improve folw table offload Aug 01 08:05:04 I'll add it to the todo list so we can fix the stuff Aug 01 08:05:17 blogic: The one that struck me last time was that all traffic (on my devices) are seen (for the lack of a better word) on eth0, making accounting hard Aug 01 08:05:42 kristrev: can you throw that into an email and send it to me ? Aug 01 08:06:03 (I mostly have routers with multiple interfaces and keep track of the data use on each of them) Aug 01 08:06:27 blogic: Sure, I will do it tonight or tomorrow. I will test a bit more so that I can (hopefully) provide some more details Aug 01 08:06:40 awesome i can get a fix for the issue Aug 01 08:10:19 I would call my issue(s) minor and all in all flow offloading works great on my devices, I am always a bit impressed when I see something-something mt7621 route 1Gbit/s Aug 01 08:10:51 or, scratch "bit" :) Aug 01 08:14:54 are there any other devices than those based on mt7621 that support hardware offloading? Aug 01 08:16:47 not yet Aug 01 08:16:57 well, using closed drivers Aug 01 08:17:07 and i have a driver for the qca8337n switch fabric Aug 01 08:17:19 and in theory this will work on all dakotas but only for wire Aug 01 08:17:53 thanks Aug 01 08:18:26 right now we are fixing up the last few issues, sending the hw offload part upstream and making the mt7621 driver work aswell Aug 01 08:18:29 ... in upstream Aug 01 08:18:41 then fix it for 7623/2/9 Aug 01 08:18:50 and then see about qca8k/8337n Aug 01 08:19:33 Sounds like a good plan. Are there any plans to backport the upstream mt7621 network driver? Aug 01 08:19:40 *as well Aug 01 08:19:52 probably Aug 01 08:19:54 not by me though Aug 01 08:20:20 I am busy on lots of background tasks that will benefit owrt in the midterm, leaving me next to no time for tree maintainance Aug 01 08:20:33 which remonds me to mail the PSI treasurer Aug 01 08:20:47 looks like I managed to organize a 10+k donation for server expenses Aug 01 08:20:52 sounds like you have a full plate :) Great to hear that flood offloading will get even better Aug 01 08:20:57 waiting on final confirmation Aug 01 08:22:51 stintel: 9584 Aug 01 08:23:07 "scons: move host build tool to a proper place" Aug 01 08:23:45 can't find that PR and have no idea how that relates to me ? Aug 01 08:24:14 ok found it, must have typed something wrong Aug 01 08:24:25 On phone. Will try to remind myself of issue but don’t think a bug more flow offloading = can’t have all the toys. Aug 01 08:25:05 stintel: maybe I'm just mistaken, but I've simply thought, that you're one of the package feed maintainers Aug 01 08:26:19 In theory we all have commit acess to packages Aug 01 08:26:37 ynezz: ah sure. but no idea about scons. I would try to get an ACK from Hauke on both the patch @ ML and the PR @ gh Aug 01 08:26:50 if I see that I'll gladly click merge for you ;) Aug 01 08:26:58 Hauke: ^ :) Aug 01 08:27:42 I don’t cos somehow github lost OpenWrt membership for me. So I have to go through the pr channels Aug 01 08:29:05 ldir: fixed :) Aug 01 08:29:29 well, I would prefer sending patches over mail, but that's life Aug 01 08:30:32 and I could of course push it myself, but I respect the estabilished workflow Aug 01 08:36:53 got "redefinition of 'struct ethhdr'", seems kernel/musl headers conflict: https://pastebin.com/NtP3ZiFv Aug 01 08:37:06 not sure if it belongs here or #musl Aug 01 08:37:07 xback: I've a .63 bump in my tree if it helps you at all - all straightforward, no sneaky Kconfig symbol changes - running on an APU2 Aug 01 08:37:37 can fix it with "#define __UAPI_DEF_ETHHDR 0" before "#include " Aug 01 08:37:48 ldir: appreciated :) bumped 4.14 and 4.19 again last night here. currently compile-testing Aug 01 08:38:07 i'll check for differences between yours and mine Aug 01 08:38:34 what is the proper way to deal with that "redefinition of 'struct ethhdr'" ? Aug 01 08:38:50 stintel: tks Aug 01 08:42:20 max_g: don't know - is this an existing package? Aug 01 08:42:46 ldir, nope, it's thirdparty code Aug 01 08:43:26 https://github.com/openwrt/packages/pull/1386 Aug 01 08:43:31 max_g: example ^ Aug 01 08:46:06 stintel, thank you Aug 01 09:57:19 Why would you like to commit directly to packages repository? When you will do PR, it will trigger CircleCI, it will check if there is Signed-off-by. Usually, packages are maintained by some people. Let's honor that. It will be checked with more eyes (more people). It will potentially avoid commits or PR like this https://github.com/openwrt/packages/pull/9594 even though I agree that commits which are Aug 01 09:57:21 inside the PR should be merged, but not like this. Aug 01 09:57:30 ynezz: ping Aug 01 09:58:28 Pepe: its fine, then it simply won't get merged. Aug 01 09:58:34 close the PR and let it be Aug 01 09:58:45 ynezz: seems like Mikrotik is messing up .. Aug 01 09:58:47 machine : MikroTik RouterBOARD 922UAGS-5HPacD Aug 01 09:59:00 machine : Mikrotik RouterBOARD 912UAG-5HPnD Aug 01 09:59:22 some are with uppercase T some with lowercase .. so both are needed .. Aug 01 10:01:14 i'll cook up a patch Aug 01 10:13:16 jow: I think there were some misunderstandings. Why don't use PR instead of pushing it directly to the repo? By doing PR, it will be at least compile tested. Yeah, it's not perfect, but at least something. Aug 01 12:42:56 Hi! About ath79 building vs source only in 19.07 branch. I've read the chats of the previous days but it still not clear to me which are the ath79 problems, are related to the kernel version?. I added support to LibreRouter in ath79 only because I understood that ar71xx was fixes only. We didn't upstream the LibreRouter support in 18.06 because of this. Maybe in 19.07 not all the ath79 devices should be built, but only the ath79 o Aug 01 12:42:56 nly and the devices that are known to be working good? Aug 01 12:44:09 SAn: it looks like ath79 will be built aswell as lots of people are asking for it Aug 01 12:44:22 I don't think that any devices are working bad on ath79 now. Aug 01 12:45:16 SAn I don't know exact answer to every detail, but yes ath79 will be the future and any new development should happend towards that, and that ar71xx is planned to drop after 1907 Aug 01 12:46:25 ..but it's still different to develop the master branch and then decide what exactly do in stable releases Aug 01 12:46:46 Initially ar71xx was meant to be dropped with 19.07, but not all devices have been ported. Than it was decided to have the 4.14 kernel for ar71xx. And now we drop ath79. Aug 01 12:48:15 It makes no sense to me. A year ago there were badly ported devices on ath79, that didn't really work. Now after we fixed Ethernet, IRQ and PCI issues it is quite stable for a release. Aug 01 12:49:25 Where I can read chat archive? Aug 01 12:50:12 I think that general tought was/is that ath79 still isn't basically as widely ported as ar71xx, but whatever the details be, ath79 is the path yo go when developing anything new related Aug 01 12:52:49 I see 2 good options: to leave both, or drop ar71xx. 18.06 branch will be supported for some time. Aug 01 12:56:15 it looks like we will have both in 19.07 Aug 01 12:56:33 That will motivate to port other old devices. If they are not ported, it means that nobody needs it. We have many new ath79 devices added Aug 01 12:56:53 It will be a shame if they won't have a release for a year or two Aug 01 13:04:10 thanks all for the clarifications :) Aug 01 13:05:06 pilot6: here are the logs http://logs.nslu2-linux.org/livelogs/openwrt-devel/ Aug 01 13:27:41 yooo Aug 01 14:25:53 Why does libubox have no tests? Are there any reason? What if I write some? Aug 01 14:27:14 Oh, I was wrong, it has some Aug 01 14:48:24 nazar01: you are welcom to write more Aug 01 14:48:30 we lack tests at a lot of places Aug 01 17:18:42 stintel: ynezz: I am not intrested in scons any more and also not an expert Aug 01 17:42:58 Mmmmm, scones. Butter than jam. Aug 01 17:43:31 Hauke: just your ack to move it would be nice though :) Aug 01 17:43:40 actually clotted cream then ham Aug 01 17:44:40 jam Aug 01 17:44:43 oh god - I can't type Aug 01 17:48:33 Hauke: it's just about moving scons to packages feed, where it belongs, the functionality is same, as a bonus we don't need to build scons everytime anymore Aug 01 18:10:00 ldir: clotted cream and bacon sandwich Aug 01 18:14:36 I've had 2 migraines today so not making any sense Aug 01 18:47:57 ldir: I've had none and not making sense either, so thats okay Aug 01 20:12:23 fwiw, time make -j1 tools/scons/compile takes 11 seconds on my build box Aug 01 20:57:36 ynezz: could you please point me to a really "pretty formated" dts file in openwrt.git? I'd try to modify clang-format to be somewhat compatible Aug 01 21:13:43 sooo... 19.08 now? Aug 01 21:26:33 i think it'll still be called 19.07 Aug 01 21:37:25 blogic: was reading backwards, was getting rather concerned when I read clotted cream and bacon first :) Aug 01 22:12:36 jow thanks for the new modal dialog fix for luci screenreaders can read the dialogs now. **** ENDING LOGGING AT Fri Aug 02 03:01:07 2019