**** BEGIN LOGGING AT Fri Jun 07 02:59:57 2019 Jun 07 06:39:17 morning Jun 07 07:31:56 mornin' all Jun 07 07:34:15 jow: good morning Jun 07 07:34:27 jow: i'm scanning the bugs for a change, an noticed this one: https://bugs.openwrt.org/index.php?do=details&task_id=2225&order=id&sort=desc Jun 07 07:34:35 any more action needed? Jun 07 07:53:22 morning Jun 07 07:53:41 BTW I'm wondering if it's somehow possible to get cli/API/RPC access to the Flyspray Jun 07 07:54:17 I've just checked out flyspray git, but couldn't find such interface Jun 07 07:54:41 just 'docs/AUTHORS.txt: Much xml-rpc code by Angus Hardie' Jun 07 07:57:54 xback: this indeed is an issue that might be worth discussing. Personally I would love to move our wireless things very close to upstream since I'm afraid that we'll not really be able to support wifi stack issues in the long run Jun 07 07:58:44 xback: on the other hand, upstream wireless tends to frequently break corner cases (e.g. wds) as well Jun 07 07:59:35 but at least we can direct users / ask ourselves there when things do not work. Right now they'll probably not be able support our backports + patches variants of drivers Jun 07 08:01:45 ynezz: I can give you ssh/cli access so you can meddle with the mysql db directly if that heps Jun 07 08:02:45 jow: maybe it would be worth to have a menuconfig option? "use built-in mac80211" Jun 07 08:03:20 I'm also more in favor of just using the upstream mac80211 and update it via kernel bumps Jun 07 08:03:47 especially since ath9k doesnt change that much these days Jun 07 08:04:24 and ath10k is more "simple" as work is offloaded to closed binaries Jun 07 08:05:44 nbd: what are your 2 cents on above? Jun 07 08:05:57 releases with mac80211 from kernel, snapshots with backports? Jun 07 08:06:33 ynezz: as a method of being able to test without changing default behaviour Jun 07 08:07:08 keep everything as-is for now, like a transistion period, but being able to use the built-in mac80211 easily Jun 07 08:08:00 xback: blogic and me did speak about this various times in the past - to have an option to simply use builtin mac80211 Jun 07 08:08:16 but time etc. So it wasn't implemented yet Jun 07 08:08:33 so we are past Inception phase :p Jun 07 08:09:07 I also think that mac80211 moves slowly enough these days [for the drivers we're interested in] that there's probably not that much advantage for wireless backports anymore Jun 07 08:10:12 my main concern is that some people reported issues due to potential incompatibilities if the versions between mac80211 and kernel are getting to far apart Jun 07 08:24:51 jow: I still don't know how to approach this, but my overall idea (I've proposed this already to lynxis) is to use some time next week (very low priority) to cleanup old/stale PRs/issues on FS/GitHub Jun 07 08:25:23 + Patchwork of course Jun 07 08:25:28 ynezz: yes, that makes sense. Generally auto-close things after 6 to twelve months Jun 07 08:25:38 we also discussed this on the development list a while back Jun 07 08:25:45 great Jun 07 08:26:01 it might upset some contributors but overall it makes sense. All big projects do it Jun 07 08:26:34 if you care enough, just re-submit Jun 07 08:26:37 maybe it's possible to send a mail to the submitter 1 month + 1 week before auto-close? Jun 07 08:26:57 auto-close email is good enough Jun 07 08:27:03 I was thinking about counting towards the last activity Jun 07 08:27:14 making another comment would reset the expiry timer Jun 07 08:27:22 yep, makes sense Jun 07 08:27:32 indeed Jun 07 08:46:05 will you be both in hamburg? Jun 07 09:05:40 I'll be there, landing in Hamburg on Sunday around 21.00 Jun 07 09:08:45 ynezz: jow: my main concern for using in-kernel drivers would be that it would take longer for newer drivers/features/support to reach us (e.g. wpa3, 802.11ax, 6 GHz) unless we start backporting a lot more; which would somewhat go against what OpenWrt makes interesting as alternative firmware for (newer) wireless routers Jun 07 09:22:59 then there's the issue that different kernels will have different features/bugs, so we'll get more backport requests/unclear bug reports. this could be avoided partially by using the backports for the older kernel, and the backports version as the testing kernel's release. but then we would have gained nothing in regard to maintenance burden; on the contrary, we would now need to update backports more often Jun 07 09:22:59 kernel Jun 07 09:53:33 KanjiMonster: valid points Jun 07 09:58:40 If current model works, lets stick to it (?) :) Jun 07 09:58:58 but that's just, like, my opinion; realistically I wont be the one maintaining that, so those that will should have the final say Jun 07 09:59:32 (Assuming other proposed way wouldn't be ultimately any less beneficial) Jun 07 10:01:18 Me neither, but I do generally like OpenWrt because it always thrives to be excellent, and that I wouldn't like to lose Jun 07 10:03:19 thriving to be excellent can be a hindrance though, as you might avoid doing anything in fear of it not being excellent enough Jun 07 10:05:57 "anything worth doing is worth doing poorly" :) Jun 07 10:06:32 I'll be asking for some advice in a minute or two. Completely unrelated I'm struggling a bit mentally at the moment, I think related to the thought of flights & flying to Hamburg. Jun 07 10:06:42 anyway... Jun 07 10:08:51 yesterday I submitted a backport of my act_ctinfo module to openwrt & after fixing a dependency issue all looks well. Jun 07 10:09:13 If avoiding trying because end result needs to not suck, there is already flaws at toughtprocess then :p Jun 07 10:10:22 just to add some stuff to the mac80211 discussion. Currently, bumping the version is a huge task. I think maintenance and backporting will be easier as it's only a change once in a while Jun 07 10:10:30 and not all changes at once upon bumping Jun 07 10:10:32 It needs userspace to make the module actually do anything useful. I have an upstream iproute2 patch which has been through several review cycles and is now sat waiting I think for David Ahern to accept (or not) Jun 07 10:10:34 Ofcourse there is matter of how to tell some poor lad that "make it better", THAT can be depressing of done poorly Jun 07 10:11:57 ldir: I think you need to resubmit without the RFC part of the subject, as I see that Toke has also mentioned Jun 07 10:12:05 xback: whatever the actual doers deem to be best is the proper way, I'd say Jun 07 10:12:31 kristrev_: it has been resubmitted without RFC, and with a manpage Jun 07 10:12:41 I'm trying to find it in patchwork Jun 07 10:12:44 ah, ok, sorry. Did not see that Jun 07 10:13:37 http://patchwork.ozlabs.org/patch/1109931/ Jun 07 10:13:59 olmari: the lad telling can be themselves, see "perfectionism (psychology)" Jun 07 10:14:02 I see it now. I was confused as the thread with the RFC had a more recent reply and appeared on top of my search list Jun 07 10:14:18 I am clearly one of those people that are not so good at checking hit number two, or three ... :) Jun 07 10:15:03 lol - no I agree it is confusing that the most recent reply is about an earlier submission. Jun 07 10:15:14 anyway, I probably interrupted you in the middle of what you where about to say :) Jun 07 10:15:17 and it's discussing the 80 column formatting thing. Jun 07 10:15:56 yes, that is a bit confusing in iproute2. Well, the whole coding style of iproute2 is a bit confusing if you ask me :) Jun 07 10:16:45 KanjiMonster: Can, but would you think OpenWrt would be as awesome as it is if blindy accept anything and everything.. so in other extremity there would be fear for someone getting sad if not accept low quality code ;₩ Jun 07 10:17:00 In essence the question is 'would anyone get upset if I pushed the 'post several reviews, hoped to be accepted upstream' patch to iproute2 into openwrt's iproute2 package ? Jun 07 10:18:18 olmari: it's always a case-by-case, but sometimes "good enough" is ... enough Jun 07 10:18:26 Since the kernel module is available, and your patch looks very much destined for an accept, I would vote for pushing the patch. Only thing would be if the API/commandline changes, but I guess that is not very likely? Jun 07 10:19:20 KanjiMonster : yes, i didn't say needs to be perfect ;) Jun 07 10:19:51 I see that David sometimes takes a little while before replying. It took around one week with my so far only iproute2 submission, and then one more week with minor clean-ups Jun 07 10:20:02 kristrev_: I would like to think that sufficient bikeshedding and review has taken place for any more command line changes to happen. Jun 07 10:20:28 Yes, my impression as well Jun 07 10:20:50 and Toke has more or less ACKed it, so ... Jun 07 10:21:52 ok I think I feel brave enough :-) Jun 07 10:24:10 olmari: yeah, but as I mentioned, it doesn't help if the inner self says it needs to be. Unfortunatley I often struggle with that. I recently finally submitted a patchset to upstream that I had lying around for ugh .. 3 years? because I couldn't decide which implementation is the better one, as neither one seemed good enough to me, and couldn't come up with a better option Jun 07 10:24:22 the coding style thing is a bit frustrating, I copy/pasted some already existing code and that got rejected, so it's a shame that the checkpatch rules haven't been applied to the existing stuff to prevent newcomers picking up incorrect(bad?) habits. Jun 07 10:25:02 and don't get me started on 'reverse christmas tree' not being checked by checkpatch :-) Jun 07 10:26:16 KanjiMonster: we need to re-educate you ;) Jun 07 10:28:34 ldir: that's because there's a common code style, and each subsystem has its own set of rules on top of that, and "reverse christmas tree" AFAIK isn't a common rule Jun 07 10:29:22 olmari: if it only were that easy ;) Jun 07 10:30:14 ..but boy doesn't it feel good when accomplished something hard? ;p Jun 07 10:31:14 TIL about reverse christmas tree. I wish that today I hadn't learned that.... Jun 07 10:32:46 * ldir apologises Jun 07 10:36:45 ldir: I assume you are aware of the strict mode of checkpatch? Jun 07 10:38:18 I know it exists - I'm not yet in the habit of running it like that all the time though. Jun 07 10:38:21 olmari: yeah, that's not how that works. there's only dread that it breaks something essential, has serious flaws, wouldn't be good enough, etc ;) Jun 07 10:38:47 also --terse is nice to make the output more compact Jun 07 10:40:33 KanjiMonster: thanks for those hints - I'll check'em out Jun 07 10:46:06 KanjiMonster but maintainer of a thing will tell you if it isn't good enough, so why stress too much about that ;) Jun 07 10:47:07 but if a maintainer runs checkpatch and it doesn't find anything then it shows to them that you've taken the time to care enough about formatting Jun 07 10:47:30 my perspective is "try not to give any reason to reject the patch" Jun 07 10:49:35 Ldir: sure, but that is not the same thing even.. or quite the other end of same whole complex :) Jun 07 10:56:19 ..that is part of trying to make code to that 'good enough' state... but even if.you gail, they will tell you... again kind of pointless to worry about what maintainers will say... either way you did try, you either succeeded at once or not, but also learned then.. :) Jun 07 10:56:49 olmari: this isn't a voluntary choice - it's just how some people's mind works. There always is an inner voice nagging, critisizing, reminding you of everything that could be wrong. sometimes louder, sometimes quieter Jun 07 10:56:54 ..even if you fail* (lol... ) Jun 07 10:58:38 KanjiMonster: yes, but that can be psyched to minimize it.. I don't say it is neccesarily easy either.. and some stuff works better than something else for individual Jun 07 11:00:07 For some, they need to constantly kind of literally remind themselves (if not by others) to "go for it" :) Jun 07 11:06:27 olmari: "go for it! what could possibly go wrong?" mind: "thanks for asking! I already prepared a 2 hour presentation about that!" ;) Jun 07 11:07:25 * ldir bravely pushes the iproute2 user space bits of act_ctinfo Jun 07 11:08:32 ldir: cool Jun 07 11:10:31 what about fallen Christmas tree https://patchwork.ozlabs.org/patch/1086628/#2162316 ? :) Jun 07 11:10:49 KanjiMonster: that's where the self-psyching needs to be done.. more proper remind for oneselve would be "maintainers will tell" Jun 07 11:14:21 but you shouldn't upset them too often with such basic stuff or they'll start ignoring you :) Jun 07 11:15:16 ynezz: oh, nice one ;D Jun 07 11:15:47 ynezz: that would be in the part if figuring out "good enough"... Jun 07 11:16:08 olmari: what if you are the maintainer yourself? Jun 07 11:16:34 Deciding "this is good enough" is not the same as "lets wilfully push the thing I already know is crap" Jun 07 11:17:12 KanjiMonster: I am for some thing, not in openwrt scope tough.. nor anything too popular or big as openwrt Jun 07 11:24:18 in general, maintainers need to not blatantly bash "unperfect" code for no reason, but need to tell what is wrong with it... the one pushing the code need to understand that code might not meet requirements, and if maintainer then tells what's wrong with it, it doesn't mean they hate you or your code, but to take it as learning tool and improve oneself.. Jun 07 11:30:05 where I personally fall down in that process is that if I'm already coding right at the limits of my skill/knowledge (and I usually am) then the response of "do it differently" without obvious guidance leaves me in limbo. Jun 07 11:30:48 I'm a bit confused about wireless-device field hwmode. Does 11a mean 802.11ac? Or does it mean 802.11a so I need to hwmode=11g and htmode=VHT* Jun 07 11:31:24 Neighbor11111113: hwmode is the band to work on, so 11g = 2.4 GHz and 11a = 5GHz Jun 07 11:31:36 here's (a coincidentally very relevant example) https://lore.kernel.org/netfilter-devel/5E006285-FB1F-4948-87BE-BD1B8D0321E2@darbyshire-bryant.me.uk/ Jun 07 11:31:54 Ahh thanks KanjiMonster, because the original 802.11a was 5ghz as well right? Jun 07 11:32:01 right Jun 07 11:32:07 very cool, thanks! Jun 07 11:32:39 hwmode values are way confusing nowadays, as there is gazillion of standards... but dunno would poking with it make it any better now Jun 07 11:33:03 htmode then configures ofdm(11g/a)/11n/11ac/11ax etc Jun 07 11:33:50 11ax is fun, it reintroduces 2.4GHz support Jun 07 11:38:18 KanjiMonster, isn't 11b and 11g hwmode the same? I quickly googled 802.11b and it also uses 2.4Ghz range Jun 07 11:39:10 KanjiMonster, also how do you get 11a/b/g for htmode? I assume you don't put anything there. Then for 802.11n you put HT*, 802.11ac put VHT* and have no idea what for 802.11ax Jun 07 11:44:02 Neighbor11111113: once upon a time hwmode actually configured 11a/b/g - nowadays the code only checks for a or not-a. not sure if there is a way to force 11b only. leaving htmode empty will disable 11n/ac Jun 07 11:44:24 11ax isn't supported yet AFAICT Jun 07 11:46:50 Neighbor11111113: a short google suggest 11ax will be then HE* Jun 07 11:56:35 Great thanks KanjiMonster Jun 07 11:59:40 hauke, nbd: anyone tried STA-WDS with PSK2 lately? to me it looks like the Linux packet socket fails again when the interface sits inside a bridge Jun 07 12:00:27 when i put the WDS-STA into a bridnge, it fails to authenticate with error 2=PREV_AUTH_NOT_VALID Jun 07 12:00:47 when it's not inside the bridge it just works Jun 07 12:00:59 (using ath10k on ipq4019) Jun 07 12:43:37 ynezz: thanks for following up with upstream on that ath79 irq patch. Jun 07 12:52:37 ynezz: I also guess that when they revert it from stable the patch will have to be re-added as a local backport :-) Jun 07 12:55:59 dangole: https://git.openwrt.org/?p=openwrt/staging/xback.git;a=commit;h=f7248a1a242eb601947e10f4a65db75f927326d6 Jun 07 13:02:16 Well that's another email sent off to Pablo Ayuso asking for help/clarification on exactly he meant in the review. Jun 07 13:05:13 ldir: indeed, but this is a proper way, we've backported that IRQ legacy code removal from 5.1 to our 4.14, we need to backport that fix as well Jun 07 13:06:47 I doubt, that anyone is using upstream ath79 for anything else then development, but still it should be left in the working state Jun 07 13:09:55 ynezz: I didn't realise that the irqchip stuff was a backport Jun 07 13:11:43 I've found out yesterday, while looking for explanation of this weird behavior Jun 07 13:27:07 Is there any man page or tutorial for jsonfilter? Jun 07 13:31:38 Wow it's pretty damn cool, same syntax as Json except @ is used as this. Very cool! Jun 07 13:41:28 xback: yes that's it. good that i asked ;) Jun 07 13:44:32 xback: it felt a bit like a deja-vu of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=576eb62598f10c8c7fd75703fe89010cdcfff596 Jun 07 13:47:33 xback: I reckon this fix from your staging tree can and should be merged in master asap. I'd do that after testing it, ok? Jun 07 13:58:36 dangole: some people already reported success Jun 07 13:58:45 i'll push it later today Jun 07 13:59:37 xback: nice. thanks! Jun 07 14:01:40 dangole: I also have a backport for 18.06. will push them both Jun 07 16:30:27 dansan: no I haven't tried it, there was a patch which is not yet upsteram merged into OpenWrt to fix problem with 4addr mode on ath10k Jun 07 16:30:46 dansan: I wanted to answer daniel golle Jun 07 16:50:16 stintel: ping Jun 07 16:50:25 jow: ping **** BEGIN LOGGING AT Fri Jun 07 19:32:03 2019 Jun 07 23:43:22 ldir: pong Jun 08 00:09:07 stintel: some of the builders have dropped offline & was wondering if you were able to give them a kick? **** ENDING LOGGING AT Sat Jun 08 02:59:57 2019