**** BEGIN LOGGING AT Thu Dec 19 03:00:12 2019 Dec 19 09:48:11 build #228 of brcm63xx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/brcm63xx%2Fgeneric/builds/228 Dec 19 09:49:08 build #229 of oxnas/ox820 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/oxnas%2Fox820/builds/229 Dec 19 09:55:30 build #226 of lantiq/ase is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fase/builds/226 Dec 19 11:51:29 build #222 of arc770/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/arc770%2Fgeneric/builds/222 Dec 19 12:47:09 xback: will you create a patch updating the kernl version, or will your next patch come in 2020? Dec 19 12:47:54 Hauke: already in my staging since yesterday Dec 19 12:48:06 i'll probably push to master later after compile -testing Dec 19 12:48:12 this will be the last bump for this year from me Dec 19 12:50:09 xback: thanks for the information Dec 19 12:54:01 KanjiMonster: what about this one ? https://patchwork.ozlabs.org/patch/1193526/ (ath79: enable all space on Netgear ar9344-based WNDR routers) Dec 19 12:54:24 KanjiMonster: it's unclear from the discussion and the patch wasnt rejected, so ok to apply? Dec 19 12:55:42 Hauke: what about this one https://patchwork.ozlabs.org/patch/1209969/ ? (kernel: ath10k-ct: provide a build variant for small RAM devices) Dec 19 12:55:46 looks good to me Dec 19 12:56:51 ah, I could test this on the litebeam Dec 19 12:57:12 stintel: so can you handle it please? Dec 19 12:57:18 you can add my Acked-by Dec 19 12:57:25 or Reviewed-by Dec 19 12:57:40 ok, I'll fire up my build box, it's been down since the last power outage Dec 19 12:57:49 thanks! Dec 19 12:57:49 stintel: and you can ping me on IRC should you need any mods to it Dec 19 12:57:56 Thank you ynezz for caring Dec 19 12:58:12 BTW: what about the 4k sectors on tiny? Dec 19 12:58:13 https://patchwork.ozlabs.org/patch/1201036/ Dec 19 12:58:22 adrianschmutzler: already in my staging tree Dec 19 12:59:11 thanks. because I'd really like to have that backported to 19.07 before release, so ath79 is consistent if sysupgrade might be a problem there Dec 19 13:01:39 > git pw patch update --state "Under Review" 1209969 Dec 19 13:01:42 did this work :P Dec 19 13:02:05 apparently but it did not set the delegate Dec 19 13:03:37 ynezz: sry, handwerker in the house replacing the gas-therme carelessly breaking stuff left and right, no time or nerve for that currently :/ Dec 19 13:03:51 KanjiMonster: no worries Dec 19 13:07:11 stintel: fixed :] Dec 19 13:08:37 PaulFertser: stintel: just wondering if 'lowram' wouldn't fit better (it's shorter) then 'smallbuffers' Dec 19 13:08:48 ynezz: PaulFertser: I like the solution for ath10k-ct Dec 19 13:09:27 I would prefer if you apply the smae patches just provide a different define line -DATH10K_SMALL_BUFFERS Dec 19 13:09:56 small buffers OR low ram (smallbuffers Vs lowram) ? Dec 19 13:10:13 what do they use in QSDK? Dec 19 13:11:37 Hauke: I can rework the patches that way, how soon do you need that? Also, I have no idea about the best naming "smallbuffers" kinda makes everyone think that not only it consumes less RAM but also it's likely to be slower in certain conditions. Dec 19 13:11:46 I do not have QSDK, so haven't check. Dec 19 13:13:12 My current plan is to release 19.07 at the first weekend next year Dec 19 13:13:17 ynezz: thanks. apparently I need the --delegate option to `git pw patch update ..` but then I get: {'delegate': ["User 'stintel' is not a maintainer for project 'OpenWrt development'"]} Dec 19 13:13:21 ¯\_(ツ)_/¯ Dec 19 13:14:03 * stintel updates git-pw Dec 19 13:15:23 should probably submit that ebuild to gentoo rather than keeping it in my overlay and forgetting to update it Dec 19 13:15:38 Hauke: I chose to apply those patches separately for easier syncing between mac80211 patches and ath10-ct. Dec 19 13:17:03 PaulFertser: we can also update the mac80211 version Dec 19 13:19:34 Hauke: ok, so I add #ifdef ATH10K_SMALL_BUFFERS to those two patches in ath10k-ct, send a new version, mac80211 patches can be updated later if at all desired (I guess there's no need since they weren't changed a single time since introduction). I'd also expect the target maintainer to specify the -smallbuffers (or -lowram?) version to be installed by default for obviously affected devices. Dec 19 13:19:36 do we want to selct the small buffer ath10k-ct version automatically on some devices? Dec 19 13:20:00 I think that makes sense Dec 19 13:20:03 +1 Dec 19 13:20:12 I'd say it certainly makes sense for all devices with 64 MiB or dual ath10k on 128 MiB. Dec 19 13:20:14 PaulFertser: ok fine with me Dec 19 13:22:05 About the naming I'll count on your opinion folks. In my current biased view smallbuffers imply worse performance, lowram not obviously so (probably one can think of a different tradeoff there). Also, for many usecases big buffers might be bad (bufferbloat), not sure if it affects ath10k anyhow. Dec 19 13:23:52 ok, makes sense Dec 19 13:26:03 My patch is (and will be) only compile-time tested! Dec 19 13:27:25 I have a 64MB device I can use to test :) Dec 19 13:28:21 stintel: does it fail for you with current master? It should, especially if you run LuCI. Dec 19 13:28:38 PaulFertser: I've seen OOM on that device, yes Dec 19 13:33:17 hauke: what to do with the lantiq DTS changes? should I continue to wait for a tester or just merge them as four eyes have at least seen the code ... Dec 19 13:35:04 adrianschmutzler: aren't your changes based on xdarklight's changes? Dec 19 13:35:18 xdarklight: did you had a look at adrianschmutzler dts changes? Dec 19 13:36:10 Hauke: yes, but I only build-tested, too. Dec 19 13:36:53 I do not have a lantiq device at hand now, just traveling for xmas vacation Dec 19 13:36:55 though my renaming is unlikely to break anything beyond build Dec 19 13:37:18 ynezz: the gcc patch changes the gcc 7.4.0 patch, but we already updated to 7.5.0 Dec 19 13:37:35 ynezz: I also have it in my local tree Dec 19 13:38:16 Hauke: ok, so you're going to push it? Dec 19 13:38:24 ynezz: fine with me Dec 19 13:38:27 thanks Dec 19 13:47:43 In ath79/image/generic.mk does it really need padding to BLOCKSIZE _before_ append-rootfs? Dec 19 13:48:19 I guess the answer is yes for "ubi"? Dec 19 13:53:53 What's your opinion wrt to the LEDs that get their trigger from DT? Is it OK that they're not present in the system uci config at all? Dec 19 14:28:52 pkgadd: I see Dec 19 14:31:14 I have a tplink 4300 that has been in running as an AP for a few years.. lately it just drops wifi, I would need to reboot or login and restart wifi Dec 19 14:31:45 so it doesn't stop working, just wifi stops responding (still broadcasting though) Dec 19 14:31:51 is this something fixable, eg change caps, or is it time to retire the device? Dec 19 14:32:44 btw I flashed various versions of OpenWrt including trunk, and the issue persists, so I'm guessing its likely hardware Dec 19 14:38:14 abenz: you can try another known to be good PSU. Dec 19 14:42:05 KanjiMonster: I will try that Dec 19 15:00:38 ynezz: all my questions whether X works were answered with "yes, still works", so I don't have any objections there Dec 19 15:04:15 KanjiMonster: thanks! Dec 19 17:05:12 ynezz: the following two patches have author/SOB mismatch: Dec 19 17:05:19 https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=commitdiff;h=1659d83e0dbf82013853125fb1b319bde0b5076c Dec 19 17:05:26 https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=commitdiff;h=8b1eaa147c21129273f3864597e1c6e73db7e589 Dec 19 17:06:17 adrianschmutzler: how so, I see a SoB from author on your links Dec 19 17:06:32 author has to be first SoB Dec 19 17:06:58 and two more: Dec 19 17:07:05 https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=commitdiff;h=f499146c568ad2cfd741f7427c18e29cd098a436 Dec 19 17:07:13 https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=commitdiff;h=f3cb86621651680b5a881ec1f10b889679f4d8a1 Dec 19 17:07:26 at least for what I know Dec 19 17:08:13 Well, yes, usually people add their SoB lines as needed to the bottom. Dec 19 17:08:22 But it's not essential. Dec 19 17:09:51 SoB means "I know this is proper free software". I do not think it matters much who knew it first or something :) Dec 19 17:13:17 but the from line is the author, and in this case I think the first SOB is the main author. By the way, I just wanted to notify ynezz, he will decide on that. Dec 19 17:13:40 thanks for checking Dec 19 17:14:41 i think this was also discussed in the PR in the first place ... Dec 19 17:15:30 I'd like to know the rationale for future reference. Dec 19 17:16:28 PaulFertser: I always do it this way: From and first SOB for the original author. And then add SOB below for the changes to the initial version in chronological order Dec 19 17:17:20 adrianschmutzler: yes, that's customary, but I also would like to know if and why this needs fixing if it went another way for whatever reason. Dec 19 17:18:41 SOB is not related anyhow tracking authorship. You can add your SOB even if you didn't alter anything and just passed the patch along. Dec 19 17:19:16 but you would still add it at the bottom then, and not change the From field Dec 19 17:21:40 Yes, you'd add it to the bottom usually, I do not argue with the Linux submitting-patches guide. Dec 19 17:24:28 so, the "first" author would still be the first "SOB", unless he didn't put a SOB at all. Dec 19 17:30:32 I mostly struggle in this context in the rare cases where I take a small patch from somebody and build something bigger from it. So, while the initial idea is not mine, I still feal like the author of the patch as it is essentially a new patch after all. And I haven't really found a good way to address this situation by the existing codes. Dec 19 17:31:24 just let git add it Dec 19 17:32:02 e.g. you grab a patch from patchwork with `git pw patch apply XXXXX`, you do your testing, then `git commit --amend -s` and done Dec 19 17:32:54 and don't ever remove existing SoB Dec 19 17:33:06 that would be the usiual approach, yes. Dec 19 17:34:07 I think the reason for the initial point of discussion was that the patch was created differently (or split), so that the From was replaced. Dec 19 17:34:21 The patch guide says you can use Co-Developed-by if appropriate. If it's a really new patch then I'd ask author if he or she is ok with changing the From as well. Dec 19 17:36:08 I never understood the use of Co-developed-by, as it has to be immediately followed by Signed-off-by anyway. Dec 19 17:36:40 But looks like that's the separation of authorship and SOB Paul mentioned at the beginning Dec 19 17:58:19 hi, I've a router with a broadcom 43217 wifi chip and I'm using the b43 driver Dec 19 17:58:40 the connection is little poor, it has low speed and sometimes its unstable Dec 19 17:59:26 i'm using openwrt 18.06 and also the SoC has a 5Ghz wifi card that isnt detected Dec 19 18:00:05 i've find that there are other drivers like brcmsmac and wl but im not able to find Dec 19 18:00:23 someone knows how to improve the wifi connection? Dec 19 18:12:33 franlego98: default OpenWrt images usually have the best drivers available, if you're unhappy with your broadcom device the usual advice is to get something without broadcom. Dec 19 18:25:17 PaulFertser: yes, i know that broadcom it just a piece of shit, but i want to see if a can get something better in this device Dec 19 18:25:31 at least a 2.4Ghz stable connection Dec 19 18:28:34 now i only get 5mbits/s of speed Dec 19 18:47:38 franlego98: what router is this? Dec 19 18:48:07 There's no good solution for broadcom in OpenWrt. Dec 19 20:21:36 When using GIT download method, why is .git/ removed from the archive? How is the application supposed to know its version? It runs "git describe --tags" and gets OpenWrt tree version instead :) What am I missing? Dec 19 20:34:50 adrianschmutzler: I blocked a bit of time on Saturday to test our combined PRs. I can boot test 2x VRX200 boards and 1x ARX100 Dec 19 20:36:13 also thank you for not ignoring my PR (I have very limited time at the moment due to personal reasons, so not having to resolve conflicts really helps me) :) Dec 19 20:48:19 xdarklight: thanks, that sounds good. As indicated in the PR already, I just change DTS paths. So, it should be enough to flash one or two devices and check whether they boot. Dec 19 20:52:03 so, this should be quick. what would be more time-intensive is my other PR https://github.com/openwrt/openwrt/pull/2622, but that's completely separate and shouldn't bother you at the moment. (But I would be happy if you could test this on your devices, too, when you have more time ...) Dec 19 20:54:33 adrianschmutzler: good to know. I'll test the main PR with priority and then try #2622 with the time that's left **** ENDING LOGGING AT Thu Dec 19 21:08:38 2019 **** BEGIN LOGGING AT Thu Dec 19 23:02:58 2019 Dec 19 23:25:28 am I the only being annoyed by the "latest git HEAD" commit subjects? Dec 19 23:25:43 at the time of writing it, git HEAD always means latest, so the latest is redundant there Dec 19 23:26:02 * stintel hides **** ENDING LOGGING AT Fri Dec 20 03:00:11 2019