**** BEGIN LOGGING AT Thu Nov 07 02:59:57 2019 Nov 07 06:22:39 rr123: In my experience, mt7603 is fairly stable. I have not had any issues since SMPS-support was added at the beginning of this year Nov 07 06:22:58 I do agree that it is no ath9k, but for me that is mostly related to features and not the stability of the driver Nov 07 06:25:03 I agree that ipq40xx is nice, but I am experiencing issues with USB (which is important for me and my use-cases). The host controller has a tendency to die when devices are disconnected Nov 07 07:53:44 pkgadd: the mikrotik hap-ac² is a ipq40xx *and* cheap, but is a pain to support regarding wireless Nov 07 07:55:15 I tried and gave up, and I haven't checked rmarko's progress on this Nov 07 07:57:00 zorun: interesting device, prices seem o.k. (~60 EUR), but not really cheap enough to get that one instead of e.g. the AVM Fritz!Box 4040 (~70 EUR new, less used) - and the used market doesn't seem to exist yet Nov 07 07:57:16 but yes, it's something to add to the list of devices to look out for Nov 07 07:58:13 pkgadd: I should add it's good-looking too :) compared to the bulky EA6350 for instance Nov 07 08:00:45 hmm, don't know if I like the weird dice linke LED at the front, but (within reason) I don't really care about looks in technology Nov 07 08:02:51 the price delta just isn't quite enough to prefer an unsupported (difficult) device over something easy and supported (but yeah, I'll keep an eye out for used ones which might) Nov 07 08:11:30 hello, i am new to procd and would like for someone to have a look at my init for the haproxy package: https://pastebin.com/353KtkwS Nov 07 08:12:16 it works as expected in my tests but if there are some obvious gotchas i would like to know before i make a PR Nov 07 08:31:38 jow: ping Nov 07 09:43:37 aparcar[m]: pong Nov 07 09:45:32 they didn't exactly wait very long for feedback. Nov 07 09:47:15 karlp: indeed, was just about to tell that the init script has issues Nov 07 09:50:56 I've added some to the inprogress haproxy PR. Nov 07 10:04:48 @karlp thanks for the information on github. i had to leave irc because of meetings... Nov 07 10:06:52 alright, i will change stop_service and reload_service to use procd_send_signal Nov 07 10:12:19 Hmm... I confused by wireless configuration atm. I'd like to set MCS 4 (ath9k) to avoid instability due to minstrel probing higher rates, but afair basic_rates / supported_rates is for non HT-rates, isn't it? (c.f. https://openwrt.org/docs/guide-user/network/wifi/basic) Nov 07 10:12:38 is there a way to set the MCS manually? Nov 07 10:15:05 where did this "Extra packages" top level menu come from? it's all one person's apckages? Nov 07 10:36:07 gladiac1337: you do not need these procedures at all Nov 07 10:36:44 it uses non-standard signals. Nov 07 10:37:02 reload wants usr1, not hup, and stop wnats usr2 for .... no idea... Nov 07 10:38:04 procd_set_param reload_signal USR1 Nov 07 10:39:07 I thought we expose the term signal too, but apparently not Nov 07 10:40:36 might make sense though to introduce a procd_set_param term_signal ... as well Nov 07 10:40:44 right now its hardcoded to TERM Nov 07 10:40:50 https://lxr.openwrt.org/source/procd/service/instance.c#L597 Nov 07 10:42:46 ok, I hadn't known about that stuff, and we don't have it on the https://openwrt.org/docs/guide-developer/procd-init-scripts page yet. Nov 07 10:43:20 any idea what version that would have come in with? 1907 or 1806 or master only? Nov 07 10:43:25 https://openwrt.org/docs/guide-developer/procd-init-scripts#service_parameters Nov 07 10:43:55 great, whoever added that didn't read the rest of the page :| Nov 07 10:44:28 it was me :P Nov 07 10:44:35 at least it's there .) Nov 07 10:44:40 we can edit it later :) Nov 07 10:44:44 the rest of the page was a wall of text, so I didn't bother to read it Nov 07 10:45:00 I don't have time to do it this morning I'm afraid but Ið'll leave the tab open to try and get to it. Nov 07 10:45:38 your table is a much more detailed version of the comments in the top section :) Nov 07 11:35:08 jow: procd_set_param reload_signal USR1 is nice, i will use that Nov 07 11:46:44 I am trying to get an Archer C7 to connect via wifi to RouterA and bridge RouterA's WLAN to its LAN ports. That seems to be a lot more complicated than I anticipated. I got it to work with relayd for IPv4. Can I use relayd to get it to work with IPv6 (getting IPv6 router adverts at LAN ports etc) also? How? Alternatives? Nov 07 12:11:15 woshty: use wds Nov 07 12:11:25 woshty: change router A wifi mode from AP to AP-WDS Nov 07 12:11:34 woshty: change router B wifi mode from STA to STA-WDS Nov 07 12:11:55 thne simply bridge lan and wifi and router B Nov 07 12:12:09 to enable wds via uci, simply set "option wds 1" on both wifi-iface sections Nov 07 12:12:29 is that now available for all wifi? isn't it an atheros only solution? or is it standard now? Nov 07 12:12:38 its available on all mac80211 drivers Nov 07 12:12:53 sweet. Nov 07 12:13:21 so not brcm_f_mac then, as that's only using cfg80211? Is that the correct understanding of the layers? Nov 07 12:13:37 I would guess so, but rmilecki might know more Nov 07 12:14:02 could be that it also provides the appropriate hooks for AP_VLAN (which it is under the hood) Nov 07 12:14:17 one thing is odd... i got rid of stop_service() und start_service() to let procd let it's thing and this does not work Nov 07 12:15:00 additionally, i saw that using pidfile created a pidfile with the wrong pid Nov 07 12:15:04 karlp: woshty: i don't know if that's supporetd by brcmfmac Nov 07 12:15:13 is there something wrong with the way i start haproxy? Nov 07 12:16:06 gladiac1337: do you ensure that haproxy stays in foreground is not daemonizing itself? Nov 07 12:16:17 *and is Nov 07 12:16:43 jow: at least it _should_ since I removed the daemonize parameter... Nov 07 12:17:38 oh, the haproxy configuration has it's own daemon-parameter which was enabled in my config Nov 07 12:17:53 its a good test case Nov 07 12:18:02 could you try passing "-db" to the cmdline? Nov 07 12:18:11 that should override that and force it back to foreground Nov 07 12:18:42 according to documentation it is only meant for testing Nov 07 12:18:54 also - it disabled multi-process-mode Nov 07 12:19:02 ah, thats not good :) Nov 07 12:19:16 and -W ? Nov 07 12:19:49 I already use -W. I intend to enable this in future packages by default Nov 07 12:20:10 which haproxy version is that? Nov 07 12:20:45 https://cbonte.github.io/haproxy-dconv/1.7/configuration.html#3.1-daemon claims that "-db" is the proper way to counter "daemon" in the config Nov 07 12:20:54 but might have changed in the meanwhile Nov 07 12:20:59 it is 2.0 Nov 07 12:21:02 ah ok Nov 07 12:21:21 https://cbonte.github.io/haproxy-dconv/2.0/configuration.html#3.1-daemon Nov 07 12:21:26 still makes the same claim though Nov 07 12:22:29 it seems the proper usage would be haproxy -W -db ... Nov 07 12:22:52 https://cbonte.github.io/haproxy-dconv/2.0/management.html Nov 07 12:23:11 see under -db Nov 07 12:23:33 ah I see, ok Nov 07 12:24:15 but you are right, the documentation is not really explicit in that regard... Nov 07 12:26:00 the old approach was to let haproxy create the pid and work with that Nov 07 12:26:28 yeah, thats not ideal Nov 07 12:27:14 i am testing -db right now... Nov 07 12:28:58 well it works but i am still not sure if that is the way to go Nov 07 12:34:50 maybe procd needs something like the 'forking' unit-type as it systemd has Nov 07 12:37:13 RouterA is not an openwrt device. What is WDS? Nov 07 12:37:46 if you don't control both ends, it doesn't matter what WDS is ;-) Nov 07 12:39:31 For most WDS-like setup, without control on upstream device, would then be wifi with relayd (was it called also pseudobridge on old wiki at least if I remember correctly) Nov 07 12:39:48 woshty: if you don't absolutely need bridging, you can route instead Nov 07 12:42:56 I will go with -db for now. now i need to fix reloading... I currently do "procd_set_param reload_signal USR2" for that Nov 07 12:44:28 it does not work. INIT_TRACE=1 does not show the actual "kill -USR2 PID" so i think it's safe to assume that it does not invoke it, right? Nov 07 13:04:35 well procd only triggers a service reload if anything changed from procd's pov Nov 07 13:04:40 the cmdline will stay the same Nov 07 13:05:04 and unless your register all involved configuration files using procd_set_param file ..., procd will see no change in runtime state and ignore the service reload Nov 07 13:08:54 hmm... so should i just use 'reload_service() { procd_send_signal haproxy '*' USR2 }'? Nov 07 13:09:32 that just works fine Nov 07 13:16:30 i could add the main haproxy.cfg as a procd file. however, the reload in my service_trigger will not work that way Nov 07 13:36:43 olmari: I do not know how to get relayd to work with both IPv4 and v6. Nov 07 13:37:50 I don't remember offhand how it worked, but what I understood it is more of L2 trickery, but I still could be totally off... I haven't used said method ever myself, thus no first hand experience Nov 07 13:40:58 olmari: I am having relayd up and running right now but struggle to get any kind of v6 running. Nov 07 13:44:11 woshty: that's to be expected, IPv6 doesn't support IPv6 Nov 07 13:45:08 what, on the other hand, is unexpected :) Nov 07 13:46:00 woshty: for ipv6 you probably need to play with NDP proxy mode Nov 07 13:46:50 woshty: create a new alias interface wwan6 or similar on top of wwan, set it to dhcpv6 Nov 07 13:47:25 Oh well, https://oldwiki.archive.openwrt.org/doc/recipes/relayclient anyways, true that no mention of ipv6 oin most sense (disabling dhcp yeah but otherwise) Nov 07 13:47:51 jow: I tried that, that seems to freeze things and gets automatically reverted after reboot. Nov 07 13:47:57 so maybe you are correct.. tough it was kinda hack anyways :) Nov 07 13:48:12 woshty: then in the lan interface, head to dhcp server, ipv6 settings and change all services to relay mode Nov 07 13:48:17 jow: I am kind of surprised how bad support for v6 and this usual use case is. Nov 07 13:49:05 the described procedure works for me Nov 07 13:51:49 jow: did set everything to relay already, I will try the wwan6 setup again. Nov 07 13:53:57 oops, sorry, that was meant to read relayd not supporting IPv6 Nov 07 13:56:13 about a year ago(?) there were some patches proposed to netdev which claimed to help relayd supporring IPv6 as well, they were rejected as broken Nov 07 14:36:38 how did ntpd get compiled in 19.07 branch? mine failes with this libeven pthreads issue that was fixed on master, Nov 07 14:37:20 but 19.07 has it built this morning Nov 07 14:48:15 On 19.07, sendmail won't build for me; says it's missing db_create Nov 07 14:48:17 I have been running a lantiq-xway device (FB7312) with multithreading enabled for quite some time now (>2 month) and have not encountered a problem with it. Are there strong reasons not to enable multithreading by default? Nov 07 14:52:03 kristrev_: i did quite some testing with mt76/7603e 2.4ghz on mt7621, it depends on the STA side, i have machines connecting to mt7603e stably for days, other machines had all kinds of disconnections(e.g. brcm wifi STA in my PC), all machines had no issues with other wifi AP as long as there is no 7603e on AP. it's quite obvious to me mt7603 is not reliable for certain STAs. Nov 07 15:25:06 rr123: Yeah, that used to my experience, but I had not any issues or gotten reports of any issues for a long while. Though, I do miss mt7602 Nov 07 15:25:35 When I look at what are used in "professional" products like Aruba, Cradlepoint, etc., they all seem to converge on ipq40xx. I guess they have a reason ... Nov 07 15:34:31 they're based in america and get wined and dined by american silicon vendors? :) Nov 07 15:36:50 MIPS haters Nov 07 15:37:22 haha Nov 07 15:37:40 I will go with MIPS haters Nov 07 15:42:08 wait, i thought the next big thing is risc-V Nov 07 15:42:51 depends if you have silicon to sell already or not.... Nov 07 15:43:43 risc-V might be the next big thing, but you know these guys only update their hardware every couple of years Nov 07 15:44:05 kristrev1: i tested mt76 late 2018, just dusted off my zbt1326 before i dump them to trashbin, maybe i need retest them with 1907 Nov 07 15:44:15 * karlp just installs libevent2-pthreads and moves on with life. Nov 07 15:44:22 who knows what the next generation of products will be, 5g will be an interesting test of performance Nov 07 15:45:27 I'm going to presume that ntp builds in the buildbots because something else had sleected libevent-pthreads already. Nov 07 15:45:52 5g is a hype i feel, you need 10x more towers, good for dense areas like big cities, other areas will still use 4G i believe Nov 07 15:46:34 5g might be a hype, but you dont want to be left behind :) Nov 07 15:46:34 it's pretty much like putting wave2 wifi on a big and tall tower near where you live Nov 07 15:47:07 karlp: build slave is docker container, *.buildinfo is available, so it should be quite easy to take a look Nov 07 15:47:26 rr123: very different wavelength Nov 07 15:47:38 well 5g has BW areas from "low freq" where LTE etc lives, to get "longer range" stuff, (while AFAIK no sub 1GHz definen for real rural stuff... and then high freq for really the high BW and density areas, goes up to 38GHz or something like thast, fro mmemory Nov 07 15:47:43 DonkeyHotei: yes but both are too high to go far Nov 07 15:47:56 I also agree, LTE is plenty for most use-cases. In my office I measure ~120 Mbit/s on cat. 6, and the network provider already has enabled cat 20 Nov 07 15:48:05 ynezz: wasted enough time on build crap alreday the last few days (not all openwrt) I'm just poking tripolar to look at it again for 1907, and moving on. enough pain already today :) Nov 07 15:48:21 So I do see what they are getting at, but ofcourse one also does not blindly follow the ever-same marketing "the NEXT-G is awesome and solves all your problems" :D Nov 07 15:49:15 I just need somethign to query busybox ntpd with, and I could drop ntpdate anyway :) Nov 07 15:49:39 Will be interesting to see when the switch from USB to PCI for modems will be forced Nov 07 15:49:57 And how that will affect SoC choices Nov 07 15:50:52 But LTE's problem is the basic one that what it is allways, device density... sharing (the BW) isn't caring in tihis case, high BW stuff in 5G will allow decade more devices on same squaremeter (without suffering wit hBW too much) Nov 07 15:56:02 Yeah, though I have to admit that even in areas with high density I get decent speed Nov 07 15:56:17 Though, since I am base in Norway my definition of "high density" might be slightly off Nov 07 15:57:23 kristrev1: and for the record, I Nov 07 15:58:13 ...I'm not specifically advocating 5G, but I also do see the potential, if nothing else, with the high freq stuff, inrelated to what else 5G is designed to bring Nov 07 16:05:54 * rr123 feels his future is beam-formed while microwave-cooked Nov 07 16:06:33 olmari: No worries, I hadnt written you down as 5G ambassador. Yet ... :) Nov 07 16:07:17 Yes, I also believe 5G has a lot of potential and cool use-cases Nov 07 16:07:20 huawei has all his interest pushing for 5G, in china many cities' population is larger than an europen country, talking about density Nov 07 16:08:56 US is not dense at all, 5G is for the most part not attractive. the future is 2nd generation or Iridium satellite-based 6G, made by Tesla, powered by batteries in the sky Nov 07 16:08:57 In most broader specs, I see 5G potentially also doing/making possible to use way more MIMO "channels" than LTE does.. that also helps with general connectivity, despite freq Nov 07 16:09:40 MIMO was also one of biggest leaps LTE made compared to 3G, while ofcourse there is never the one thing that betters everything Nov 07 16:09:42 There is a 5G test network close to the office, so just waiting for the first modules. Though, the core network is still 4G so it is only a matter of new frequencies and more speed Nov 07 16:10:19 Then I need to start designing 8H, to up the game ;) Nov 07 16:10:49 hehe Nov 07 16:11:22 I wonder which protocol will be used to communicate with the devices, if it will be qmi, mbim or at Nov 07 16:11:39 hopefully not at :) Nov 07 16:11:42 Also to comp. I do also see 5G being foremostly an urban thing, there it will help the most, if somewhere Nov 07 16:11:43 may it rest in peace Nov 07 16:11:52 My impression is that we are unfortunately moving back to at-commands Nov 07 16:12:28 Since there is so much vendor specific stuff in each device now. Probably the features are available via QMI, but good luck getting that spec Nov 07 16:12:51 well.. AT commandset isn't good or bad thing themselves... the actual networking channel tech is the thing more so (while oculd very well do without AT too) Nov 07 16:12:55 at commands can be customized like hell too. Nov 07 16:13:16 indeed Nov 07 16:13:18 welcome to wild west =) Nov 07 16:13:25 That is true, but the nice thing with for example QMI is that you have a (fairly) common interface to several devices Nov 07 16:13:39 where do you see things "moving back to AT" ? Nov 07 16:13:45 https://www.zdnet.com/article/microsoft-defender-atp-is-coming-to-linux-in-2020/ Nov 07 16:13:47 oh dear :) Nov 07 16:13:59 karlp: sure they can.. but at commands and "is it qmi" isn't exactly relating to eachothers directly either was my point :P Nov 07 16:14:19 for example Quectel has a lot of features hidden under a properietary at+qcfg command Nov 07 16:14:40 Fortunately Quectel is one of the good guys, their documentation is very good and readily available Nov 07 16:14:56 stintel: opkg install defender ? Nov 07 16:15:19 ynezz: profit! Nov 07 16:15:37 stintel: mm well... some company infras rely heavily on A antivirus on linux server... to scan the Windows stuff before it get's onto stupid workstations ;D (I know it's inrelated to that "news") Nov 07 16:16:14 to microsoft-the-oss-torjan-horse we already had clamav etc Nov 07 16:18:23 olmari: Agree, perhaps I was inaccurate. I have started to rely on a combination of QMI and AT to configure the modems I need to use Nov 07 16:18:46 by the way i was told nokia lost the battle for 5G already Nov 07 16:18:58 "lost the battle for 5g" meaning what exactly? Nov 07 16:19:13 I just see that I have to implmenet more and more stuff as AT-commands, and that makes me a bit sad since I am lazy and like to recycle code :) Nov 07 16:19:16 tabloid Nov 07 16:19:23 but they are struggeling to get contracts Nov 07 16:20:01 the core problem is, as its CEO said, they used FPGA for 5G in the design, which "They give you flexibility, they give you time-to-market advantage, but then they’re expensive,” Nov 07 16:20:21 when you're expensive, you're dead Nov 07 16:21:18 Ericsson seems to have the European market pretty much locked down. If you take a look at Nokias share price, it is quite easy to spot when the news about 5G was made public Nov 07 16:21:34 That FPGA decision, about the components used in the company's 5G equipment, now threatens Nokia's 5G competitiveness against chief rivals Ericsson and Huawei Nov 07 16:22:04 I'm also generally interested to test 5G, but nothign to test on my area and won't pripably be for year or two at least... but more so I truely hope that eventually when 5G is the norm, I still can get a modem (be it separate box or "simple" addin card" that I stil lcan get IP passthrough from it onto openwrt router =) Nov 07 16:22:20 kristrev1: yes NOK is on my watch-list to buy, i nearly bought a lot at $5, now it's $3.5 Nov 07 16:22:21 well FPGA can be turned onto relatively cheaper purpose build chip, but need ofcourse enough quantity to do that Nov 07 16:22:40 I mean almost all projects use FPGA or relevant stuff on proto stage... on mas markets then never... on few thousands of specialty devices then likely also Nov 07 16:23:24 kristrev1: That I know too, that still doesn't mean lost ultimately, but if Nokia doesn't up their game fast, then they definately lose :D Nov 07 16:23:57 fpga for prototyping, large volumes you do ASIC or SOC, which is why FPGA vendors' revenue stay flat for years Nov 07 16:23:59 olmari: If there is one thing history has taught me, it is to never underestimate Nokia Nov 07 16:24:20 The managed to survive Elop! Nov 07 16:24:36 did they? Nov 07 16:24:46 s/Elop/Flop/ Nov 07 16:27:48 Nokia bought rival Alcatel-Lucent in a €15.6 billion ($17.3 billion, at today's exchange rate) deal at the start of 2016 and said its decision to use FPGAs was prompted by that move and the integration challenges that came with it. Nov 07 16:28:08 Depenging on definition of survival :D Nov 07 16:28:27 satisfy_dependencies_for: Cannot satisfy the following dependencies for wpad-wolfssl: libwolfssl19 Nov 07 16:28:55 what the deuce Nov 07 16:29:02 I would say that a large downsizing, change of focus and probably corporte restructure are minor actions after the Elop has visited Nov 07 16:30:30 they will probably never be the Nokia of old, but I think the Nokia of today is doing pretty good Nov 07 16:31:38 sigh, where the heck does that even come from. `git grep wolfssl19` returns nothing Nov 07 16:32:02 @adrianschmutzler: hi, 4 days between introducing RFC patch and merging it? Nov 07 16:32:38 I was in the middle of writing my comment about it :| Nov 07 16:33:22 @pepe2k There was initial feedback and then nothing for a longer period, so I didn't expect any further feedback. Nov 07 16:33:37 Sorry. Nov 07 16:34:05 kristrev1: fun thing is that after seling phones off, nokia still wasn't exactly small company, while ofcourse fraction of what it was =) Nov 07 16:34:17 So, 3 days does not qualify for "a longer period" ... Nov 07 16:34:41 @adrianschmutzler: where did you get the feedback, on GitHub? Nov 07 16:34:51 I'd say wait at least 1 week, preferably 2 Nov 07 16:35:30 that should give most people who _want_ to review it time to do so Nov 07 16:35:41 yeah, 2 weeks would be much better, especially for a change which renames default hostname :) Nov 07 16:36:09 ynezz: Just submitted the patch changing u4019 over to reset-gpios. Guess it is safe to deprecate phy-reset-gpio now Nov 07 16:36:26 I provided some of the feedback on the ml, but only on the commit regarding labeled mac Nov 07 16:36:41 I was referring to the feedback on the earlier version of the patch. Nov 07 16:38:00 Concerning waiting time: Sorry, I had to guess, and I had the impression that the discussion ceased at some point. Nov 07 16:39:13 not really, two weeks is often necessary for people's other tasks, who aren't fulltime on this. Nov 07 16:39:29 Nevertheless, I would be interested in your comments on the topic Nov 07 16:39:31 np, these things happen, but keep in mind the 1-2 weeks next time Nov 07 16:39:40 @adrianschmutzler: on my mail I see just two versions, first sent 03112019... and day later v2, not RFC anymore? Nov 07 16:39:51 adrianschmutzler: Every project seems to have own schedules... for this big as openwrt is, indeed maybe even that 2 weeks isn't insanely long to wait for courtesy if nothign else Nov 07 16:40:06 there was a v3 Nov 07 16:40:33 the only risk here is that with waiting longer, something might be forgotten again entirely Nov 07 16:40:55 anyway, it's master, not that big a deal, and it can always be reverted / modified Nov 07 16:41:07 that PR is over 1 year old... Nov 07 16:41:18 @ynezz: GH vs. list problem, again... Nov 07 16:41:25 14 days is insane, it's development branch Nov 07 16:41:43 @pepe2k v3 was sent three days ago: https://patchwork.ozlabs.org/patch/1189175/ Nov 07 16:41:56 people usually don't care unless it hits the git tree :) Nov 07 16:42:08 And RFC for v1 was mainly due to it being untested, that's why I removed it for v2 Nov 07 16:42:30 pepe2k: then we need to fix that GH issue :p Nov 07 16:42:45 @ynezz: or are busy with their day jobs/lives... 4 days is definitely too short for RFC Nov 07 16:43:54 wait, we changed the default hostname? Nov 07 16:44:01 * karlp grins Nov 07 16:44:17 @jow: :D Nov 07 16:44:31 Okay, q.e.d. Nov 07 16:45:08 Hostname now is OpenWrt-ddeeff, for label MAC address with aa:bb:cc:dd:ee:ff Nov 07 16:45:17 I would say for such changes, ideally there should be at least an ACK from someone on the team. but where do you draw the line "for such changes" Nov 07 16:45:58 I don't care to know what/how big change it was that is being talked now... the more stuff changesetintroduces, the more I'm willing to wait... As indeed said here, generally chjanges can be reverted too Nov 07 16:46:03 ...changes_it_introduces... Nov 07 16:46:04 and it's fine to come here fishing for an ack ;) Nov 07 16:46:10 I do it all the time lol Nov 07 16:46:45 adrianschmutzler: uhm, that looks ugly, maybe the mac part should at least have been upper cased Nov 07 16:47:06 Well, so should I revert it (at least the hostname part)? Nov 07 16:47:16 I'm unsure Nov 07 16:47:24 "I changed this one isolated thing, okay?" is kinda "whatever" and easy to revert... compared to "I introduce stuff that cnages all ubus signalling method" for example... ;) Nov 07 16:47:32 currently trying to think about what advantages we lose compared to a static host name Nov 07 16:47:51 privacy Nov 07 16:48:03 people can now see where you're exactly connected to :p Nov 07 16:48:15 why need change openwrt-->openwrt+mac? to avoid multiple openwrt installed together so they have different hostname or what Nov 07 16:48:18 I was more thinking along the line of giving user fixes, predictable points of entry Nov 07 16:48:30 @ynezz: regarding GH vs. list... I don't think there is (an easy) way to 'fix' the 'problem', it's more about preferences of developers and I'm pretty sure GH isn't on the first place for most of devs Nov 07 16:48:32 like, "ssh to openwrt.lan" or "got to http://openwrt.lan/" Nov 07 16:48:40 but in the end, its probably just bikeshedding Nov 07 16:48:55 *fixed Nov 07 16:49:23 i do have a few openwrt on the same LAN and i change their hostname manually Nov 07 16:49:27 it should be optional, I wanted to fix that before merging it, but Adrian was faster Nov 07 16:50:30 adrianschmutzler: can you revert it to an opt-in feature for the time being? Nov 07 16:50:31 a fixed name is nice for dhcp, i can blindly ping to get IP when needed Nov 07 16:50:41 Well, since the opposition is overwhelming, I think it's better to revert the hostname patch. I would keep the label MAC change, though, as it removes the uci setting for know. Nov 07 16:50:49 I am sure downstream users have uses for this Nov 07 16:50:53 adrianschmutzler: don't worry too much about it, don't revert things, get used to this backlash :) Nov 07 16:51:12 adrianschmutzler: the label mac thing is totally fine Nov 07 16:51:21 adrianschmutzler: it's just another (post commit) feedback Nov 07 16:52:02 in my case i use vm to run x86 openwrt each time it could get a new mac by default, that means for me each new build will have a new hostname to put into browser Nov 07 16:52:02 adrianschmutzler: Is the mac already set in uci? Nov 07 16:52:32 *label mac Nov 07 16:53:23 @kristrev1: I now decided for the approach without uci, as the uci config introduced to much corner problems Nov 07 16:53:49 pepe2k: patch/PR -> CI -> get at least one ACK -> merged by bot automatically (no direct push) for example Nov 07 16:53:59 @adrianschmutzler: please don't get me(us) wrong, I was actually going to ask in the mail about 'opt-in' option for that and say "I like it" :) it's only about giving others more time to think about it Nov 07 16:54:03 so, label MAC address is retrieved by get_mac_label, but directly from DT and board.json Nov 07 16:54:04 adrianschmutzler: Yeah, I was just wondering if the address was stored in uci before your commit or not? Nov 07 16:54:55 before my commit from today, address was store in uci system config IF you 1. installed a new device (no upgrade) and 2. the address was defined in 02_network Nov 07 16:55:24 adrianschmutzler: Ok, thanks. Then I have one more comment, but I am not sure how much it matters since the feature is quite new Nov 07 16:55:33 For the users having installed images in this period, the label_macaddr will remain in uci, but be abandoned Nov 07 16:55:52 jow: as a newbie to frontend, will you have some time in the future to add a section on how to use the new js-cbi to replace the old lua-cbi? a small example will help a lot. it seems the controller and view stays the same and theming too, major change is the CBI portion as far as I can tell at this point Nov 07 16:55:53 pepe2k: https://github.com/openwrt/openwrt/pull/1370 (9/11, 2018) Nov 07 16:56:04 Yes, but if someone has built something that depends on that value being in uci, their code will break Nov 07 16:56:20 (and not going via your function) Nov 07 16:56:32 So that's one of the reason why I finally decided to use board.json directly, as we are now independent of the upgrade path again Nov 07 16:57:23 "lost in github" Nov 07 16:57:26 @kristrev1: Yes, but that's really relatively unlikely and acceptable for something being in master only one month or so Nov 07 16:57:46 And that's btw why I wanted to push this better now than later Nov 07 16:58:00 Yes, I know and you know I like the board.json approach :) The case I am refering to is if someone has built something with a previous version with OpenWRT where the value was stored in uci, and then installs a new router Nov 07 16:58:02 * stintel gets lost Nov 07 16:58:27 I agree and I think it is fine the way it is, I just wanted to point it out just in case Nov 07 16:59:30 adrianschmutzler: this is what we've been doing here for years on this: https://zerobin.net/?2f7baea127300d26#vW9ka5HfE/rxMtroYmQbwQtVKA2eHSDZmUHaGll3kyU= Nov 07 16:59:39 (both setting hostname and storing in uci) Nov 07 16:59:58 I've been following your label mac and stuf with interest to see how you resolv/ed it for an across the board solution :) Nov 07 17:00:23 Well, this is obviously a huge topic for Freifunk communities Nov 07 17:00:49 90% of people will probably only has one openwrt router in the house, openwrt.lan will make life easier to locate the router, openwrt-AABBCC is to serve a small group, most of them actually know what they're doing, so while changing hostname is a hassle it is kindof expected anyways? Nov 07 17:01:44 we should set aside a name in mdns, so you cna browse for openwrt routers and just connect to the first one automatically if there's only one :) Nov 07 17:01:51 @ynezz: it only proves what I wrote before Nov 07 17:01:56 not sure about its impact on mesh network Nov 07 17:02:05 (but yeah, mdns and hostname resolution on local is a pain for cross OS, cross browser) Nov 07 17:02:17 pepe2k: "commit it and _then_ get feedback"? Nov 07 17:02:35 thats the only working workflow now :) Nov 07 17:02:46 no, it's a hammer that says the loudest wins, Nov 07 17:03:03 deploy to production Nov 07 17:03:17 So, I don't think it's a good idea to make it optional now with a quickly assembled, untested patch. So, I'd say let's do a quick vote for "keep" vs. "revert" Nov 07 17:03:18 rr123: yes, I was planning to do that Nov 07 17:03:22 that's like in USA we now prosecute whoever he/she is before we have any evidence :) Nov 07 17:03:36 for the workflow that is Nov 07 17:04:24 While I dont really have anything to say, I vote for keep and then deal with the fallout later (if there is any) Nov 07 17:04:25 adrianschmutzler: only revert 6170c46b477d4953f91b99e805a276de444913cf for now I'd say Nov 07 17:04:46 yes, vote only referring to that single commit Nov 07 17:05:11 I think appending the mac to the hostname is useful and makes it easier to deal with multiple devices Nov 07 17:05:42 I'm a non-voting gallery sitter, and i use it myself, but I think it should be reverted for now. Nov 07 17:06:15 By the way, what happens if a deivce has no label mac? Wont we then get inconsitent hostnames? Nov 07 17:06:15 why? what is it breaking? it's development branch Nov 07 17:06:29 wouldn't it be better to just make it optional? Nov 07 17:06:45 Yes, I think so Nov 07 17:06:53 from an external point of view, it looks like it might breaks things, so better revert it now and think about it (and about making it optional) Nov 07 17:07:01 Where should the option be set though? At build time? Nov 07 17:07:02 @kristrev1: It's an if/else, so if no label_mac, it will just be OpenWrt as before Nov 07 17:07:13 zorun: it's not going to brick your router Nov 07 17:07:26 i have no voting power, but if it's me, at least make it opt-in Nov 07 17:07:26 and? Nov 07 17:07:41 I do not really unterstand how this would be reasonably made optional Nov 07 17:07:47 ynezz: no but it might fail existing deployment sceanrios, test scripts or even just user expectation so let's give it a second thought Nov 07 17:08:01 ynezz: neither would changing the default ip address, but I don't recommend it just because it won't brick anything. Nov 07 17:08:29 @jow: ack, there was also discussion about SSID naming, I think it would make sense to combine both topics Nov 07 17:08:49 adrianschmutzler: can't this be done in uci-defaults script? Nov 07 17:09:37 for SSID's I'm much less opposed to the OUI suffixing if available Nov 07 17:09:52 jow: who is so crazy to be deploying latest master code? Nov 07 17:09:53 @zorun: Well, yes, but I do not see the reason behind having two default values Nov 07 17:09:55 adrianschmutzler: like, just provide macaddr_geteui(), document it, and let people that need to customize hostname do so in a uci-default script Nov 07 17:10:00 since wifi is typically off by default anywaym so either peopel already entirely rewrite the config, or edit it before activing Nov 07 17:10:19 and for these proposed devices where wifi should be on by default due to missing ethernet, it does not change existing functioanlity Nov 07 17:10:21 @zorun: That would be equivalent to removing the patch, yes. Nov 07 17:10:23 @ynezz: people who can't wait for stable releases? ;) Nov 07 17:11:06 @adrianschmutzler: what about "Image configuration" in make menuconfig? Nov 07 17:11:10 As it's easy to patch the hostname with three lines of code if desired. Nov 07 17:11:11 ynezz: there's people in the forum very vocal about recommending users to always use the latest snapshots Nov 07 17:11:25 because releases are stale, nobody cares about them, they take too long etc. Nov 07 17:11:38 sure, I do the same :) Nov 07 17:11:45 @pepe2k: I do not really think that's worth it. Nov 07 17:11:45 but I test it before Nov 07 17:13:00 Actually, I'm also more interested in the SSID topic than in changing the hostname. But that's much harder to achieve. And for that, one might actually consider a menuconfig option. Although I'd prefer on-by-default. Nov 07 17:14:32 adrianschmutzler: Perhaps an option could be to extend "Image Configuration" with a selection causing a uci-default script to be generated Nov 07 17:15:10 Okay, so the tendency goes towards revert, so I will do it. However, I'd add a second patch already introducing the function to calculate the EUI, so whoever is interested can build a manual implementation: https://github.com/openwrt/openwrt/pull/1370/commits/412fe34edeef569b2f68540ca8666cd60686d80f Nov 07 17:15:31 adrianschmutzler: you could leave that function in as well Nov 07 17:15:48 just take out the mac address setting for now Nov 07 17:15:55 sorry, the hostname setting Nov 07 17:16:30 As you wish, one commit less to do :-) Nov 07 17:16:47 I'd propose to a) write an RFC / ANN to the mailing list, announcing that the defualt hostname will change in th future [on some boards] Nov 07 17:16:49 @adrianschmutzler: and ping list about it so others can jump into discussion Nov 07 17:17:09 b) ask for feedback, especially wrt. existing deployment or device enrollment scenarios Nov 07 17:17:20 c) introduce it in 3-4 weeks if no feedback Nov 07 17:17:58 and expect another post commit feedback later from different group Nov 07 17:18:02 :) Nov 07 17:18:47 that level of sarcasm seems out-of-place Nov 07 17:19:02 for a project as big as openwrt, it's to be expected that some people will discover the change after it was made Nov 07 17:19:20 that's not a valid reason for short-circuiting everyone else Nov 07 17:19:31 (not implying this is was happened in that case) Nov 07 17:20:35 ynezz: and then you can at least point at rfc/ann discussion topic Nov 07 17:21:56 but the discussion on GH has no value Nov 07 17:22:36 it was too long, intermingled with PR revisisions Nov 07 17:22:43 didn't bother to read it Nov 07 17:23:33 the problem is that the GH thing started as PR which triggered a discussion, partly around the code, partly around the principal decision Nov 07 17:23:58 the decision that we want to change hostname, ssids etc. should be made first, then we can implement it Nov 07 17:26:58 kristrev1: so reset delay 2ms instead of previous 5ms? Nov 07 17:27:33 ynezz: many other changes introduced on GH got merged and were discussed only there... with this change I have two problems: 1. it touches very basic and important system config, 2. there was RFC, day later v3 and 3 days later merge Nov 07 17:28:46 ynezz: Yes, I followed your suggestion and tried a lower value. I agree with your interpretation of the spec and trie two, and it works fine Nov 07 17:30:51 ynezz: and maybe it's time to re-discuss and make some decisions about contributions on GH (or GL in future) if most of devs think it doesn't work Nov 07 17:32:21 I'm afraid, that the problem (lack of time/people) will just shift to other place Nov 07 17:32:32 the number of contributions won't be lower Nov 07 17:32:44 but at least all of them will be in a single place Nov 07 17:33:03 you can have them in one place today, in your email Nov 07 17:33:38 separate topic: I'm following the discussion on GL-AR NAND device support in GitHub. Due to the complexity of upgrade paths, I wonder whether it would be viable to disable building of the relevant images on ath79 (only) in openwrt-19.07 before release. Nov 07 17:34:37 @ynezz: from GH? Nov 07 17:34:47 sure, I read it only in email Nov 07 17:35:27 you just need to follow the project Nov 07 17:36:15 I also do that, but it's "noisy", i.e. many small emails that can be hard to keep track of Nov 07 17:36:15 @ynezz: ah, watching feature... Nov 07 17:36:26 too much spam Nov 07 17:36:28 even with threading (I can't imagine how it could be useful without threading...) Nov 07 17:36:36 zorun: you can filter new PRs Nov 07 17:36:51 I tied that once and got hit by someone doing hundreds of force pushes... Nov 07 17:36:57 tried* Nov 07 17:37:05 ynezz: what do you mean? Nov 07 17:37:08 Regarding GH: I personally think GitHub works well for certain tasks, e.g. device support PRs. Essentially it's a matter of taste, though. On the other hand, there is a lot of frustration among GH submitters, that won't help our image. Nov 07 17:37:39 zorun: the content of the mail is different for new PR Vs comment/action on the current PR Nov 07 17:38:09 ynezz: yes, but then you won't be aware of the discussion that happens inside a PR Nov 07 17:38:19 @adrianschmutzler: about Gl.iNet devices, is it about NOR+NAND devices which at the moment are supported with NOR image only and will get NAND support in 4.19? Nov 07 17:38:51 zorun: but you can "block stupid ideas" in the beginning :) Nov 07 17:39:19 @pepe2k Yes, effectively glinet,gl-ar300m-nor, glinet,gl-ar300m-nand and glinet,gl-ar750s . Nov 07 17:41:18 ynezz: why would anyone want to block discussion on "stupid" ideas? Nov 07 17:41:22 @adrianschmutzler: why not keep both images? when NAND is possible, just add it and let people decide Nov 07 17:41:27 also, what does "stupid" mean in this context Nov 07 17:42:15 @ynezz: during the Prague summit when we discussed GH, I had a feeling that "low quality of GH contributions" was the main objection Nov 07 17:43:01 @pepe2k: It's planned to do a kernel partition increase for support in 4.19, and by disabling those one could make sure that a certain name refers to a certain partitioning. Nov 07 17:43:06 zorun: not block discussion, just express clearly, that it's not ok to change the default hostname for a) b) c) d) and that it has to be optional Nov 07 17:43:28 (at least for released images) Nov 07 17:43:30 Hi people I have bin thinking about a new thing for make menuconfig. I think it would be useful to have a submenu at the very bottom of make menuconfig called "all selected" witch would hold all the packages and options marcked with a * Nov 07 17:44:15 And I'm not really sure how functional gl-ar300m-nand on openwrt-19.07 actually is at all. Nov 07 17:44:19 my Github mail folder currently contains >75000 unread mails :( Nov 07 17:44:34 If you unselect a feature or package it would be removed from the submenu. Nov 07 17:45:31 @pepe2k: https://github.com/openwrt/openwrt/pull/2184#discussion_r342836118 Nov 07 17:45:53 @adrianschmutzler: we usually don't drop support for devices already in tree, at least not without a good reason, as there might be users. I have both devices here, can do some testing over the weekend if you need Nov 07 17:45:53 ynezz: that's exactly the purpose of an RFC, and it's much easier to see it instead of having to search through endless PRs, most of them with no global change (just device support or fixes) Nov 07 17:46:44 actually, maybe github should be limited to adding/fixing device or target support, and all "global" changes should go through the ML Nov 07 17:46:47 just an idea Nov 07 17:46:50 adrianschmutzler: from my pov, feel free to disable/drop these devices Nov 07 17:47:18 @pepe2k: Well, I'm talking only about ath79 in openwrt-19.07, so ar71xx will remain, and ath79 was originally thought to be source-only there Nov 07 17:47:55 @adrianschmutzler: ah, then go for it, sorry, didn't read carefully Nov 07 17:48:34 zorun: that would be another fragmentation :) Nov 07 17:48:56 @pepe2k: Okay, then I would just comment out target_devices for those three devices. I don't think it's necessary to remove code, as whoever is capable of building that could also have built from master Nov 07 17:49:21 commenting out the "+= device" lines was the usual approach so far Nov 07 17:49:24 @ynezz: but maybe it would work as in general, regular users care only about getting their devices in tree and don't give a tiny... about other things Nov 07 17:50:05 @jow exactly what I plan. Will there be images created for rc1 on downloads.openwrt.org? Nov 07 17:50:16 pepe2k: I think it can only be solved with automation to some extend Nov 07 17:50:35 adrianschmutzler: yeah, they already are. But I can selectively delete some if you want Nov 07 17:51:16 @jow perfect. I will just build the commit and send you the names in about 5 min Nov 07 17:51:31 jow: exactly, CI, test that hostname is OpenWrt :p Nov 07 17:51:51 if it's green ship it Nov 07 17:52:12 ynezz: no, but ensure that all little nitpicks are covered, that the commit message is well formatted, that dtc stuff compiles without warnings Nov 07 17:52:26 no missing SoB... ;) Nov 07 17:52:30 that a radom kmod getting added does not result in interactive prompts during builds or missing dependencies in other packages Nov 07 17:52:48 right, that the S-o-b remotely looks like a normal name (capital initial letters, at least a space within it) Nov 07 17:52:49 even very well formated DTC can brick your device... Nov 07 17:53:25 true, but it does not need a human reviewer then explaining the committer that the whitespaces are off Nov 07 17:53:53 you can fetch the patches, you know that they'll build (maybe there'd even be an image artifact) and run-test them if you so desire Nov 07 17:54:02 of course you still need to look at the code Nov 07 17:54:02 sure, it's a pre-build check/step in the CI pipeline Nov 07 17:54:51 another good check would be one for unicode chracters in scripts... Nov 07 17:55:03 we just need to decide on GH / GL / something else and move forward finally Nov 07 17:55:18 merging a seemingly innocent one line change with the wrong <"> characters is not fun Nov 07 17:55:42 and no, I'll not runtime test one-line script changes Nov 07 17:56:09 CI already works in some projects out of the box https://gitlab.com/openwrtorg/project/libnl-tiny Nov 07 17:57:29 @ynezz: willing to introduce it on the mailing list and prepare for voting? Nov 07 17:57:49 it -> switch to GL Nov 07 17:58:41 pepe2k: nope, blocking https://gitlab.com/openwrtorg/gitlab-evaluation/issues/5 Nov 07 17:59:22 @ynezz: just make that as first feature to implement after the switch? Nov 07 17:59:35 @jow Please delete the ath79 images of 19.07.0-rc1 for the following three devices: glinet,gl-ar300m-nor glinet,gl-ar300m-nand glinet,gl-ar750s Nov 07 18:02:33 before making any steps regarding gitlab we should figure out if we use openwrt or openwrtorg Nov 07 18:02:34 ynezz: https://about.gitlab.com/handbook/support/internal-support/#i-want-to-see-if-a-group-name-is-free-or-able-to-be-claimed-for-a-potential-customer Nov 07 18:02:35 should we ask more nicely? Nov 07 18:04:42 adrianschmutzler: openwrt-19.07.0-rc1-ath79-generic-glinet_gl-ar300m-lite-initramfs-kernel.bin and openwrt-19.07.0-rc1-ath79-generic-glinet_gl-ar300m-lite-squashfs-sysupgrade.bin are fine? Nov 07 18:05:29 yes, lite can stay, its not NAND and thus won't be affected by any changes. Nov 07 18:07:10 Thanks. Nov 07 18:07:13 what's wrong with GH just curious Nov 07 18:07:44 @rr123: Only few devs active there Nov 07 18:08:06 adrianschmutzler: should be gone, please reconfirm at https://downloads.openwrt.org/releases/19.07.0-rc1/targets/ath79/ Nov 07 18:09:17 @jow Fine, thanks. Nov 07 18:10:45 rr123: ideally we'd combine the openwrt infrastructure, currently it lives at places like, github PR, patchworks, bug.openwrt. also promoting open source services Nov 07 18:12:04 aparcar[m]: thought github can do that? anyway i too am concerned about github as it's now a M$ company Nov 07 18:13:45 * rr123 uses gitea Nov 07 18:18:17 jow: are the snapshot build keys removed from the rc1 build? I'm getting different base-files with my rebuild script (left origin, right rebuild) https://rebuild.aparcar.org/19.07-SNAPSHOT/ath79/generic/packages/base-files_204-r10643-5d6308ecae_mips_24kc.ipk.html#tmpp-p_g-rk-content---.-data.tar.gz---data.tar---file-list Nov 07 18:19:24 Since 9fa061a7d3 ramips/mt7620 is fully reproducible https://rebuild.aparcar.org/SNAPSHOT/ramips/mt7620/ Nov 07 18:19:58 aparcar[m]: rc1 builds use different keys Nov 07 18:20:26 jow: where is the setup? Nov 07 18:21:03 it the same setup as master, just with a different config ini Nov 07 18:22:14 coming back to the SSID with MAC EUI topic: Would it be acceptable to change the SSID in /etc/config/wireless by a uci-default script put into base-files, since mac80211.sh starts to early to access board.json? Nov 07 18:22:29 adrianschmutzler: I guess so Nov 07 18:22:53 Okay I'll figure it out Nov 07 18:23:02 but do rc1 and 19.07-snapshot share the same keys? Nov 07 18:23:20 aparcar[m]: they should Nov 07 18:23:29 https://openwrt.org/releases/19.07/start#signature Nov 07 18:23:33 is there a summary of what's new in 19.07? Nov 07 18:23:40 Tapper: not yet Nov 07 18:23:47 That would be much easier than hacking around in mac80211.sh and would still apply the changes before wifi is started even if someone downstream removes the disabled=1 Nov 07 18:24:02 there's like a multi thousand line changelog in the wiki, but so far nobody was motivated to write a summary of it :) Nov 07 18:24:08 jow OK Nov 07 18:24:19 Are all builds uploaded? Nov 07 18:24:25 not all Nov 07 18:24:46 14 targets are missing yet Nov 07 18:25:00 they should be done by tomorrow morning Nov 07 18:25:06 how long does it take to build everything (just out of curiosity)? Nov 07 18:25:28 adrianschmutzler: if we throw all resources available on it then about two days Nov 07 18:26:16 typically it takes 4 to 5 weeks Nov 07 18:26:21 sorry, 4 to 5 days Nov 07 18:26:39 so that's what applies to the snapshots then? Nov 07 18:27:07 http://buildbot.openwrt.org/master/images/ Nov 07 18:27:22 pick a random builder and check its recent builds timeline, that will give you a rough idea of the pacing Nov 07 18:27:57 ah, interesting, I wasn't aware of that Nov 07 18:28:04 master buildbot runs a bit slower atm since I shifted most of its workers to 19.07 Nov 07 18:28:49 stable branches have no snapshots, they are only build on release tags IIRC? Nov 07 18:29:02 stable branches have snapshots too Nov 07 18:29:09 but they're typically hidden from users Nov 07 18:29:25 so it's more for build testing then? Nov 07 18:29:36 https://downloads.openwrt.org/releases/18.06-SNAPSHOT/ Nov 07 18:29:41 https://downloads.openwrt.org/releases/19.07-SNAPSHOT/ Nov 07 18:29:48 yes building and pre-release run testing Nov 07 18:30:02 aparcar[m]: it would be nice to have json files for release builds Nov 07 18:30:29 so those are just hidden by not linking them to the start page? Nov 07 18:30:44 was the ftab / external usb page removed from luci? Not there anymore. Also mwlwifi is having issues with the current hostapd package, clients connect for a few hours before the handshake disconnect and cannot be estasblished Nov 07 18:30:45 mwarning: I'm a bit shy lately asking for such things Nov 07 18:30:48 adrianschmutzler: yes. the directory listing you see on the download server is actually a perl script Nov 07 18:30:59 its programmed to hide \d\d\.\d\d-SNAPSHOT Nov 07 18:36:17 adrianschmutzler: welcome to the IRC btw Nov 07 18:36:38 what are the concerns regarding changing the hostname based on mac? Nov 07 18:36:43 aparcar[m]: FYI, I reserved gitlab.com/openwrt.org/ last year in case the project wanted to use that group name. Nov 07 18:36:45 @aparcar Don't get used to it. Nov 07 18:37:12 @aparcar Concerns were mostly that it was merged too fast so that nobody thought about the concerns ;-) Nov 07 18:37:40 adrianschmutzler: nice, so there is a chance for this in the future Nov 07 18:38:21 @aparcar: I have to reimplement and test the SSID update with uci-default, and then will submit that together with the hostname change. Nov 07 18:40:05 agb: thank you, ideally gitlab.com/openwrt would be unlocked for us, I kinda think someone else "nicely" reserved it for the project but knowbody knows who that is. Maybe we should collect those names like openwrtorg, openwrt.org openwrt-official and add a link to the readme posting to the real project :P Nov 07 18:40:40 adrianschmutzler: cool, I had multiple times the need for such a feature so I'd be happy its accepted Nov 07 18:42:28 blogic: do you remember how the buildbot signing rework patch failed? I could need this patch right now Nov 07 18:44:18 BTW: not-binding vote for hostname/SSID: lower-case or upper-case, hyphen or underscore for separation: OpenWrt-aabbcc, OpenWrt_AABBCC, ...? Nov 07 18:45:19 OpenWrt-aabbcc for me so AABBCC not overshadowing the main actor OpenWrt Nov 07 18:47:50 why not just uuid-it , what if i have more than one MAC addr et Nov 07 18:48:46 does it work for mac-clone Nov 07 18:49:43 I think I don't really understand the question Nov 07 18:50:37 which MAC are you going to use? say I have a dual-WAN device. will it be the first 3 bytes or the last 3 bytes of the MAC, if I have same model routers their MAC OUI might be the same Nov 07 18:51:22 uuid will produce a random number and could it be used to make hostname unique Nov 07 18:51:25 rr123: it will be the EUI, so the right part. And the plan is to use the label MAC address, so the one the user can easily identify on his/her case Nov 07 18:51:40 it's not about uniqueness, it's about identification Nov 07 18:53:05 i c, speaking of which, routers today should have a small oled(<$1) to display hostname and IP, really Nov 07 18:54:07 i was trying to find a small usb-with-screen to no avail, as type-A usb slave can not grab MAC/hostname info anyways, unless it's a gadget Nov 07 18:54:26 which need a OTG port and will be more expensive. Nov 07 18:54:41 ubiquiti for example added LCD to their higher end routers Nov 07 18:54:54 for hostname/IP/cpu-load Nov 07 18:56:27 lowercase please Nov 07 19:04:15 I would all so ask for host names to be lowercase . Nov 07 19:04:45 less of a pane in the ass when typing the name out Nov 07 19:04:45 they are supposed to be case-insensitive Nov 07 19:05:52 I am spelling insensitive, so putting something else in the mix.... Nov 07 19:06:10 lol Nov 07 19:12:07 anybody responsible for lantiq-xway could tell me why multithreading is not enabled by default? Nov 07 19:16:02 Mortiarty: the second thread is used for voip IIRC Nov 07 19:20:57 KanjiMonster, I have been running such a device for over 2 month now doing just WLAN and vpn (fastd) and it seems to work without a hassle. Nov 07 19:21:53 Concerning GitHub: Maybe it would already help to not describe both channels (list and GH) as equal opportunities, but to label the mailing list a preferred submission channel? Nov 07 19:22:02 So in a normal setup it would be used for VOIP, but for other purposes it should be ok to enable SMP? Nov 07 19:22:39 Many complaints on GH were limited to a "Why do you say you accept patches here if you do not care?" Nov 07 19:23:59 If the initial recommendation would be changed, it would be easier to encourage people to submit via the list if I already know a PR will rot in GH forever by its topic. Nov 07 19:24:34 But there would still be the possibility to use GitHub for the PRs where it works. Nov 07 19:25:10 And the change would be limited to changing one sentence in Submitting-patches Nov 07 19:26:56 aparcar[m]: no idea what you are talking bout :-D Nov 07 19:28:35 aparcar[m]: well, regarding those JSON files, jow had some ideas for improvements (IIRC he would prefer to have everything in one file), so I think, that it would make sense to fix this in master and then ask for backports to 19.07 via PR/patchset Nov 07 19:32:13 ynezz: okay Nov 07 19:32:57 blogic: f4aaee01faea1998b2403ffe951fe6100fb4e587 Nov 07 19:51:52 Linksys EA6350 sold at amazon for $40 while Linksys sells it for $90, i hope it's not because ea6350 has different cheaper version at amazon Nov 07 19:52:09 walmart has it for $80 Nov 07 19:52:21 more expensive than tp-link 1750 Nov 07 19:52:31 and this is ac1200 Nov 07 20:28:08 Just found that uci-defaults in package/base-files all have shebangs. Should those be removed, as uci-defaults are sourced and non-executable? Nov 07 20:28:23 e.g. https://github.com/openwrt/openwrt/blob/master/package/base-files/files/etc/uci-defaults/10_migrate-shadow Nov 07 20:35:26 rr123: 6350 has a v4 out in the wild already and you'd need v3 Nov 07 20:40:23 rr123: the CPU in the ea6350 is mutch better then the c7 Nov 07 21:13:59 @adrianschmutzler: I can't think of any other reason than debug purposes Nov 07 21:22:49 then I will send a patch to remove that, after I've tested my wifi SSID patch without shebang Nov 07 21:31:30 hm, it makes me wonder how could one find out, that it's shell script, no .sh extension, no shebang Nov 07 21:33:09 just thinking aloud about possible future CI use case Nov 07 21:34:43 Well, the question is whether tidyness isn't wrong here: A sheband won't hurt, but could be used as identifier even in non-executable script. It will however hurt the purists Nov 07 21:35:03 @ynezz: just assume everything inside uci-defaults is a shell script? Nov 07 21:35:40 it seems amazon likes to resell popular wifi router models with reduced features at a cheaper price and rarely or never specify the new model number Nov 07 21:37:28 blogic: do you remember the purpose of this? target/linux/ramips/patches-4.14/0051-serial-add-ugly-custom-baud-rate-hack.patch Nov 07 21:39:38 pepe2k: probably, good point Nov 07 21:43:39 Flipped other way, does it hinder anything or make somethign bad to have shebangs on those? Nov 07 21:45:25 That's what I meant with "wrong tidyness" Nov 07 22:07:12 swalker: This overview https://sdwalker.github.io/uscan/index-19.07.html misses some CVEs for wolfssl, curl and e2fsprogs Nov 07 22:23:58 blogic: it's added in commit f5d5cb0114a18c854d3bbd19560a84f8b077521c Nov 07 22:24:12 something about an atmel controller Nov 07 22:29:18 Hello. I just updated the ath10k-ct driver to have a 5.4 version. I just re-applied all my 5.2 patches on 5.4, could easily be regressions/bugs/etc, but quick test worked in station mode at least. Nov 07 22:32:13 russell--: linkit smart related (has atmega on board)? Nov 07 22:33:52 I had something similar on an adroino with some atheros SoC + atmel Nov 07 22:34:59 see fa137d51f5cbc678922950a6b06883c1d2141ac2 Nov 07 23:44:16 build #166 of layerscape/armv8_64b is complete: Failure [failed images] Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv8_64b/builds/166 blamelist: Kristian Evensen , DENG Qingfang , Paul Spooren , Adrian Schmutzler Nov 07 23:44:16 , Rosy Song , Daniel Danzberger , Henrique de Moraes Holschuh , Martin Schiller , Eneas U de Queiroz Nov 07 23:56:21 huh. mips has no rotate instruction. Nov 08 00:00:07 oh interesting. GCC is getting defeated on 64-bit rotates Nov 08 00:18:25 * russell-- is working with someone who wants to try to use 2.5Mbaud, was surprised when it didn't work ;-) Nov 08 01:18:35 russell--: should BOTHER be sufficient for that sort of thing? Nov 08 01:20:12 karlp: what is BOTHER? Nov 08 01:20:44 * russell-- greps **** ENDING LOGGING AT Fri Nov 08 02:59:57 2019