**** BEGIN LOGGING AT Sun Mar 29 03:01:48 2020 Mar 29 03:40:21 any one want to revue this? https://github.com/openwrt/openwrt/pull/1950 Mar 29 04:01:47 Tapper: that change is overdue. given how much backlog there is, I doubt it will make it in. Mar 29 04:05:32 what are the metrics? for lots of processors Os actually works as well or better than O2 as more stuff fits in cahce lines and so on Mar 29 04:05:51 just a blanket, "Os is crap!" claim is always a bit bogus Mar 29 04:06:20 a lot of anecdots and no numbers in that PR Mar 29 04:06:56 If I new how to benchmark I would Mar 29 04:07:48 Even tho diizzy can be a bit harsh with people I think he knows what he's onabout for the most part. Mar 29 04:09:00 They know what there are on about.* Mar 29 04:11:07 karlp: Os in OpenWrt is purely for size reasons. Mar 29 04:11:27 mvebu, x86, and the ARM stuff don't have that problem Mar 29 04:15:55 Is there a page in the wiki about benchmarking routers? Mar 29 04:22:54 The bin I built from master had luci-ssl, addblock, banip, bcp38, upnp and https-over-dns-proxy jumped from 7.41 mb to 8.5.2 mb Mar 29 04:23:44 That would of bin two big for all 8 meg flash routers. Mar 29 04:33:55 mangix: mvebu (and sunxi, RPi, etc.) probably don't really have any size issue, other ARM based targets however do. ipq40xx has a couple of devices with 16 MB flash, ipq806x starts with devices coming with 32 MB flash (and some of them having to share it with a second SOC for wifi or xDSL hardware) - while those aren't really constrained, you can't really be too "wasteful" there either Mar 29 04:37:31 You could change it just for the mvebu target? Mar 29 04:38:02 sunxi, RPi, two. Mar 29 04:39:08 It would be good to get some numbers tho! Mar 29 06:27:06 build #114 of brcm2708/bcm2708 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/brcm2708%2Fbcm2708/builds/114 Mar 29 08:00:41 Is Jeffery To ever here? Mar 29 10:48:12 * nick[m]4 sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/biFPugySIObDHojWIRVEGrnP > Mar 29 10:53:07 nick[m]4: your question is unclear and also please use non-long matrix messages when talking on channel. Mar 29 11:36:46 I have two PRs Mar 29 11:36:47 https://github.com/openwrt/openwrt/pull/2856/files Mar 29 11:36:48 https://github.com/openwrt/openwrt/pull/2597/files Mar 29 11:36:57 I just wonder, why they are not merged. Mar 29 11:41:21 because its an extremely unusual feature Mar 29 11:41:52 most people usually reviewing github PR probably have no idea at all about the code being patched Mar 29 11:42:31 besides, its only 5 days Mar 29 11:45:48 nick[m]4: also, some core devs prefer to deal with mailing list patches rather than "github pull requests", so reviewing things on github has some kind of a lesser priority. Mar 29 11:45:52 lower Mar 29 11:46:21 so, I only should send via mailing list? Mar 29 11:46:28 the other one is from december 2019 Mar 29 11:49:41 nick[m]4: it's not really "should" but in certain cases in certain areas it might be faster to get something accepted via the mailing list. Mar 29 11:50:16 k. I will send it via mailing list again. Mar 29 11:50:43 nick[m]4: I'm not sure it's recommended to resend github patches via the ML, please wait for jow or somebody else to comment. Mar 29 11:51:13 ah okay. then I just wait ;) Mar 29 12:32:07 build #349 of ath25/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ath25%2Fgeneric/builds/349 Mar 29 13:04:44 nick[m]4: some PRs wait for a year, so... that's how it is in a project driven by volunteers Mar 29 13:05:25 that's why I asked. And tried to motivate people to test my PRs Mar 29 13:05:31 what else I can do Mar 29 13:05:55 wait Mar 29 13:05:58 ;P Mar 29 13:08:33 When people send patches using git can we stop telling them to use the ML like we don't care about there PR on git? When I posted on HN about OpnWrt that was the number one complaint I got off people! Mar 29 13:10:13 It just pisses people off. It is going to get worse when we starte using gitlab two. Mar 29 13:11:45 Hi I like your progect and would like to contribute where should I send my code here, here or here. O fuck it! Mar 29 13:13:49 the community driven package feed on github works pretty well Mar 29 13:16:44 yeah! Mar 29 13:36:20 My 2Ā¢ is that the last time I submitted a patch to OpenWRT (which was admittedly quite some time ago) it took me longer to figure out how to use git-send-email properly than it took to make the patch. Mar 29 13:38:23 mamarley lol There is no dout that git can be a pane. I was just pointing out what People have said in the past. Mar 29 13:39:21 When I made a patch I had to have ldir hold my hand all the way through lol Mar 29 13:41:28 * ldir gets out the hand sanitiser Mar 29 13:42:16 * ldir likes crows - why can't this virus be called CORVID-19 Mar 29 13:47:40 :P Mar 29 13:48:03 nick[m]4: i will have a look Mar 29 13:49:41 thanks a lot!!! :) Mar 29 13:50:28 nick[m]4: poking someone on IRC usually works fairly well Mar 29 13:51:33 Tapper: to hell with github Mar 29 13:51:36 Tapper: my thoughts about GitHub is a mixed back. From my experience conversations in Mailinglists are of higher quality and the GitHub notification (even the new Beta one) does not really help Mar 29 13:52:28 slower medium vs. faster medium Mar 29 13:52:32 sometimes slow is good :) Mar 29 13:52:50 No, it's not about speed, it's about user experience and manageability. Mar 29 13:52:59 The biggest bummer IMHO is you are not able to disable the Web Editor. You are not able to do a PR for OpenWrt with it. Period. Mar 29 13:54:30 Tapper: for occassional contributors plain git is easier because you just use "git-send-email" to send a patch from your local repo, no configuration needed, just all defaults work out of the box. Mar 29 13:55:04 Tapper: with github you need to create new remote repo, push to it to a separate branch, create pull request, do not forget to push to the same branch the next time you're making a patch revision etc. Mar 29 13:55:39 PaulFertser: For me, it took probably 30 minutes to figure out the proper git-send-email incantationĀ· Mar 29 13:55:44 * ldir bangs the commit message "WHY you changed it not necessarily WHAT you changed... that's WHAT the diff is for" drum Mar 29 13:56:03 mamarley: isn't it just --to ? Mar 29 13:56:59 I don't remember; it has been too long. I also wanted to send myself a copy first just to make sure that it turned out properly and I wouldn't be spamming the list, but I do seem to remember having to do that multiple times before I got it right. Mar 29 13:57:18 there are switches for everything, CC to yourself, ... etc Mar 29 13:57:27 Oh, and I also had to make sure I got the SMTP server configuration just right, because I can't send email directly since my IP is on the Spamhaus PBL. Mar 29 13:57:33 https://www.freedesktop.org/wiki/Software/PulseAudio/HowToUseGitSendEmail/ Mar 29 13:57:57 cc to yourself is default iirc Mar 29 13:58:29 * ldir reads the above link on a regular basis to refresh the brain cell Mar 29 13:58:33 mamarley: any *nix host supposed to have a functional MTA, so git-send-email has no special needs in that regard. Mar 29 14:00:13 You still need MTA to send email from any other program. Mar 29 14:00:31 supposed to, yes... nowadays it would involve more or less postfix or alike with meh amounts of config and/or relaying to your SMTP of choise (: Mar 29 14:00:51 In the interest of minimizing attack surface, I prefer not to run Postfix on my desktop and laptops. Mar 29 14:00:57 Well, probably you can call it MSA in this specific case. Mar 29 14:01:26 Which is why I had to spend the time to get all the arguments right for sending it through the Postfix instance on my server. Mar 29 14:01:59 THB, postfix can ofcourse be configured to answer only to localhost, which is kind the usecase in some of my deployments.. I mean company SMTP and generally mailsystem is somewhere, but exactly for any local computer towork "as is" something like that is needed Mar 29 14:02:56 If you need just sending why not run msmtp? Mar 29 14:02:59 either you setup a program to handle correct settings ttowards mailserver (the regular mail-probram case), but indeed that can be shitshow for general system Mar 29 14:03:37 But you need it anyway right, you're sending emails somehow from that box anyway? Mar 29 14:04:06 ..plenty options and variations exist, but doesn't hinder the point that nto many, even more advanced users, have any such things ever set up, beacause reasons Mar 29 14:04:23 Are they not sending emails? Mar 29 14:04:28 nick[m]4: reviewed both PRs Mar 29 14:04:42 ping me when you corrected the stuff i've pointed out Mar 29 14:05:40 most common usecase is that from (GUI-)programs that needs to send mail is them to have mail-server settings... like mine bookkeeping/invoice program, or the more general Thunderbird etc Mar 29 14:05:54 thanks! I will fix that Mar 29 14:05:54 those are the easy ones Mar 29 14:06:57 olmari: MUAs are all by default using local delivery via MSA. You actually need to configure them to do something different (e.g. to contact the smarthost directly) but it's certainly not the default behaviour. Mar 29 14:08:48 PaulFertser: exactly Mar 29 14:09:44 olmari: so I guess most unix admins will tell you that it's sane to configure MTA/MSA once instead of messing with settings in different MUAs. Mar 29 14:10:06 So you have it configured anyway for regular email. And git-send-email just works thanks to that. Mar 29 14:10:49 Most end users, even more versed ones, never does such things, which was kinda my point :) Mar 29 14:12:02 "MTwhat? I can read my gmail just fine on the interwebs" or the slightly better "I have Claws-mail authing towards my mailserver anyway" Mar 29 14:13:05 Those caters suprisingly large propotion of any random sample from even, say, generally *NIX nerds Mar 29 14:13:28 Which brings up the point where this all kind of started (: Mar 29 14:13:52 ..or that was more of reasons why, starting comments was the "what" Mar 29 14:56:27 HayWo: pling Mar 29 14:56:43 ehrm, no.. Mar 29 14:56:47 Hauke: pling Mar 29 15:25:22 stintel: ping Mar 29 15:34:14 mirko: pong Mar 29 15:43:46 Hauke: [shameless plug]: do you by any chance remember why you made these extensive changes to this patch, back then: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=9261e7447ea7b8d33b70ff6ea008f2041a88e255#patch170 ? Mar 29 15:52:08 f00b4r0: not really, it was related to the changes done upstream between 4.14 and 4.19 Mar 29 15:52:20 and I hope I get the same behavior as before Mar 29 15:53:09 I think this struct erase_info does not exist any more Mar 29 15:53:19 and I think it should be save to have these information only locally Mar 29 16:03:11 build #317 of ath79/nand is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Fnand/builds/317 Mar 29 16:03:26 Hauke: I'm actually quite suspicious that this change is what broke partial erase in 4.19 Mar 29 16:04:22 struct erase_info still exists, but the patch added a few fields to it that were used by mtd_erase_callback(). These fields and that callback are removed in the changes Mar 29 16:05:21 I'll try to start back from the 4.14 version of the patch, see if I can make it wokr again in 4.19. Possibly unrelated, it also seems that CONFIG_MTD_4K_SECTORS_LIMIT is no longer honored Mar 29 16:12:25 f00b4r0: I never checked that this patch works at runtime Mar 29 16:12:33 f00b4r0: It would be nice if you could fix it Mar 29 16:12:35 Hauke: I figured ;) Mar 29 16:12:57 when you are at it, do you have some time to get this into upstream Linux? Mar 29 16:13:01 yeah, right now the archs still using 4.14 are safe, but when they switch, shit is going to hit the fan Mar 29 16:13:52 Hauke: I wish. I'm not very familiar with how that code works (I might be a bit more once I'm done fixing it), nbd would be better suited to push it imho Mar 29 16:19:47 Hauke: tmn505 also pointed out yesterday that even when it does work, it might still be buggy: http://lists.infradead.org/pipermail/openwrt-devel/2020-March/022159.html Mar 29 16:20:28 I'll see if I understand enough of the code to fix that too Mar 29 16:25:59 f00b4r0: ok thanks for taking care Mar 29 16:26:34 np, yw Mar 29 16:31:22 hmm i see Mar 29 16:31:24 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/mtd/mtdpart.c?h=v4.19&id=8f347c4232d5fc097599b711a3385722a6834005 Mar 29 16:31:40 Hauke: ^ the whole plumbing upon which this patchset relied has been removed from upstream. Mar 29 16:35:06 * f00b4r0 isn't too sure he wants to learn yet another linux subsystem :P Mar 29 16:36:14 esp when the code is completely undocumented. Because you know, who needs comments ;P Mar 29 16:36:36 anyone familiar with xrx200 SoC? I have a router that isn't officially supported but is very similar to the livebox 2.1 . I got UART mode access and want to dump the flash, any help? Mar 29 16:52:06 Hauke: you're maintaining the allwinner h6 right? maybe or maybe not you remember that i had (and still have) a weakness for devices with graphics/display support. since panfrost - a working(!) opengles2 driver implementation - and cedrus - a also working video decoding engine driver - are available for H6, I'm considering (re)starting my efforts of bringing kodi into penWrt, focusing on (surprise!) Mar 29 16:52:12 AW H6 Mar 29 16:52:32 However this will take some effort and quite likely some modifications on the platform Mar 29 16:53:07 Hauke: on a scale from 1-10: how keen on supporting this project are you? :) Mar 29 16:53:10 mirko: I do not have a H6 only H5 Mar 29 16:53:58 I have no problem when you add video suport to the sunxi target Mar 29 16:54:13 normally these devices have a lot of ram Mar 29 16:54:28 Code in Openwrt Should be wrapped after 80 chars? Mar 29 16:54:49 it might include messy/hackish workarounds for the time being (kernel wise) Mar 29 16:55:02 build #302 of mpc85xx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fgeneric/builds/302 Mar 29 16:55:09 then i might give it a try Mar 29 16:55:14 could be fun Mar 29 16:55:32 * ldir forgot he installed openwrt2020 theme - came as a shock - looks good Mar 29 16:55:40 mirko: but wigyori is currently maintaining sunxi Mar 29 16:55:53 wigyori: pling :) Mar 29 16:57:37 Hauke: thanks Mar 29 16:58:08 f00b4r0: when you get this feature into the upstream Linux kernel we do not have to maintain it in OpenWrt any more Mar 29 16:58:13 mirko: no problem Mar 29 16:58:23 Hauke: having high hopes, are we? :) Mar 29 16:58:25 mirko: which H6 board do you have? Mar 29 16:58:33 orangepi3 Mar 29 16:59:00 mirko: it is too bad the PCIe controller is broken in the H6 Mar 29 16:59:11 yes, it's a mess Mar 29 16:59:28 the opi3 even has a mini-pcie port - thanks for nothing Mar 29 16:59:59 trying to spin this aerohive ap170 up with something close, but I'm running into boot issues. built a wrt400n image (with a serial port tweak back down to the bootloader's 9600 baud) https://pastebin.com/ibBpue9Q anybody got some pointers on getting this to see the squashfs root? Mar 29 17:23:41 build #295 of apm821xx/nand is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/apm821xx%2Fnand/builds/295 Mar 29 17:53:17 build #315 of ramips/rt3883 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt3883/builds/315 Mar 29 17:59:28 ldir: pong Mar 29 18:33:22 russell--: https://bugs.openwrt.org/index.php?do=details&task_id=2899 "compiled fresh master clone without these flags -march=74kc -mdspr2 and the router now boots with kernel 5.4" Mar 29 18:36:11 Hauke: FYI there seems to be some regression with db70077668e7 ("toolchain: Update GCC 8 to version 8.4.0"), causing bootloops due to `Kernel panic - not syncing: Unexpected DSP exception`, reverting that gcc bump makes it working Mar 29 18:36:24 FS#2899 Mar 29 18:53:39 blocktrron: ping Mar 29 18:55:18 I was not that sure with the coding style. I hope it is okay. And the nullpointer stuff. Mar 29 18:55:18 Sry, it took so long.. I had to recompile and test everything again. Mar 29 18:57:20 Or someone else here, who can say if that is correct? Mar 29 18:57:32 https://github.com/openwrt/openwrt/blob/396444a07d31a2498be335577cd8f115169ed717/package/network/services/hostapd/src/src/ap/ubus.c#L1274 Mar 29 18:59:07 Or I could move the void into a newline Mar 29 18:59:37 nick[m]4: just noticed line 1296 "atenna-id". missing 'n' ? Mar 29 19:00:24 thanks! I will fix Mar 29 19:00:26 typo :S Mar 29 19:01:08 np Mar 29 19:02:03 nothing screams at me in terms of style but then I'm not best person to know. I can read it which is a good sign :-) Mar 29 19:06:16 Sometimes they do return parameters \n function name, if the number of chars is greater 89 Mar 29 19:06:18 80* Mar 29 19:30:26 aparcar: FYI there is still some leftover in the new x86 image generation code, seeing "/usr/sbin/grub-bios-setup: error: cannot open /boot/grub/boot.img': No such file or directory." in the QEMU bootlog Mar 29 19:37:59 build #256 of ath79/tiny is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Ftiny/builds/256 Mar 29 19:46:25 aparcar: this http://paste.debian.net/hidden/161e259e/ is the part you've missed, again that's only my personal (not very relevant) opinion Mar 29 20:07:37 ynezz: thank you I'll have a look Mar 29 20:07:51 ynezz: do you have an opinion regarding the device profile naming? Mar 29 20:07:58 ynezz: thanks for merging https://git.openwrt.org/247043 ! could you also backport it to 18.07? it's definitely a bug fix Mar 29 20:08:18 ynezz: the (short) conversation is here https://paste.debian.net/hidden/161e259e/ Mar 29 20:47:29 where is the uboot source for xrx200 in the openwrt repo? total noob here Mar 29 20:48:49 ynezz: i got it booting by inserting one unexecuted line, fwiw (which gives me as much satisfaction as wacking the side of a television to improve the picture) Mar 29 20:55:21 Toomoch: the lantiq-uboot package is defined here: https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=package/boot/uboot-lantiq;h=dc15e62542d3dfeeac1ebed10d2e517f47f8f80c;hb=HEAD Mar 29 20:55:26 PaulFertser: lol at thinking all *nix hosts have a functional MTA "out of the box" :) Mar 29 20:55:35 it takes an old upstream U-Boot and applies many patches Mar 29 20:56:09 russell--: what is needed to make it boot? Mar 29 20:58:28 Hauke thanks Mar 29 21:01:03 Hauke: it was the heisenbug line, the dump_stack() call, which implies instructions just got shuffled a little. Mar 29 21:03:33 karlp: well, the host admin is supposed to configure one when any need to send emails surfaces. And Debian had MTA in standard install for many years. Mar 29 21:04:13 yeah, I know why you think this, it's like expecting people to read the "online documentation" refuring to things in /usr/share and so on :) Mar 29 21:04:22 I mean, you're _right_, but it's not relevant to reality :) Mar 29 21:10:25 is this not a good place to ask for assistance on a bring up? Mar 29 21:11:29 russell--: so the dump_stack() itself failed? Mar 29 21:11:57 it was never called Mar 29 21:12:30 i inserted dump_stack() immediately above the panic() call, but it didn't panic Mar 29 21:12:41 so, the branch was never taken Mar 29 21:14:01 russell--: when something gest miscompiled the problem is often gone when you add debugging into the specific place ;-) Mar 29 21:14:18 I had the same problem, when I debug a compiler problem Mar 29 21:14:21 last time Mar 29 21:15:42 http://sprunge.us/MRWss2 Mar 29 21:15:47 that was my patch Mar 29 21:15:51 (to the kernel) Mar 29 21:20:09 russell--: do you need some specail kernel configuration to see this problem? Mar 29 21:21:29 nope, i did the bisecting with a vanilla configuration Mar 29 21:21:40 i only saw it on the wdr3600 though Mar 29 21:21:50 not some of my other ath79 device Mar 29 21:21:51 s Mar 29 21:22:17 I do not have a netgear_wndr4300, only a TP-Link WDR4300 and TP-Link TL-WR1043N Mar 29 21:23:27 for example, buffalo wzr600dhp and netgear wndr3800 don't panic Mar 29 21:23:47 different SoC Mar 29 21:25:50 would be interesting to see if another ar9344 device saw it too Mar 29 21:27:03 ls -al target/linux/ath79/dts/ar9344_* Mar 29 21:27:26 yes this is also AR9344: https://bugs.openwrt.org/index.php?do=details&task_id=2928 Mar 29 21:29:26 your tplink wdr4300 appears to be an ar9344 Mar 29 21:32:53 russell--: now I see it too, but only when booting from flash Mar 29 21:32:56 Hauke: I just added the config stub I used when I was bisecting to the ticket Mar 29 21:33:38 hmm now I se it also with the ram disk Mar 29 21:34:16 does this only happen with kernel 5.4? Mar 29 21:34:21 yes Mar 29 21:34:42 or, at least, i hadn't seen the exact same thing on 4.19 Mar 29 21:34:55 ah ok, could be that I tested kernel 4.19 with the new gcc on this device only Mar 29 21:37:37 tl-wdr3600 and tl-wdr4300 are exactly the same device, the only difference is the WLAN card/ number of chains (300+300 MBit/s vs 300+450 MBit/s) Mar 29 21:38:02 updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html Mar 29 21:38:31 pkgadd: yes I see the problem now too Mar 29 21:38:43 I wil try to debug it Mar 29 21:57:39 f00b4r0: did you get any further on that 802.11r-on-ath*k issue? Mar 29 22:06:23 DonkeyHotei: switch to OtA instead of DS (dunno why DS is owrt's default btw), it seems to be working now Mar 29 22:07:55 russell--: does this CPU has the DSP extension? Mar 29 22:08:59 russell--: the crash hapens in the save_dsp() function Mar 29 22:09:04 happens Mar 29 22:09:11 and Linux thinks it has a DSP extension Mar 29 22:09:40 save_dsp() is called by arch_dup_task_struct() Mar 29 22:15:36 f00b4r0: hmm, just that one option? no other changes? Mar 29 22:27:40 ok it has the DSP extension Mar 29 22:37:32 DonkeyHotei: none. Signing off, ttyl Mar 29 22:37:45 ty Mar 29 22:38:51 russell--: this looks intresting: git.kernel.org/linus/edbb4233e7efc37dbebb10f7774b38c64080dd66 Mar 29 22:38:55 https://git.kernel.org/linus/edbb4233e7efc37dbebb10f7774b38c64080dd66 Mar 29 22:39:14 this was added in kernel 4.20 Mar 29 22:43:11 russell--: I will have some sleep now Mar 29 22:44:04 KanjiMonster: I saw that you removed some DSP code from brcm63xx in the upstream kernel Mar 29 22:44:38 do you know something about https://bugs.openwrt.org/index.php?do=details&task_id=2928 Mar 30 00:39:49 btw, in my latest pull there are a bunch of config recursive dependency warnings Mar 30 01:04:17 funny. CentOS in a virtual machine has lower latency than native Fedora 31 Mar 30 01:04:47 * mangix thinks he has to reevaluate his OS choices Mar 30 01:05:51 Hi, all, I'd like to contribute to the mt76 driver. Is it preferred to use the openwrt-devel mailing list for this? Or would it be better to submit issues and pull requests to the openwrt/mt76 GitHub repo? Mar 30 01:06:14 cyrozap: none. linux kernel mailing list Mar 30 01:06:21 specifically linux-net Mar 30 01:06:43 mangix: Ah, I see. Thank you! Mar 30 01:07:03 most of the devs respond there Mar 30 01:07:13 including lorenzo and stanislaw **** ENDING LOGGING AT Mon Mar 30 03:00:00 2020